2024-04-19 15:07 AEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000002mercuryBugpublic2007-09-21 15:482007-10-03 14:17
Reporterwangp 
Assigned Topetdr 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000002: equivalence types in instance declarations
Descriptionmmc accepts the LHS of an equivalence type in an instance declaration even when it would not accept the type on the RHS, e.g.

:- type list_int == list(int).
:- instance tc(list_int) where [].

If that's not actually a bug, then there is a bug when intermodule optimisation is enabled. ":- instance tc(list(int))." is written to the .opt file and produces an error message when that .opt file is used for another module.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000002

juliensf (administrator)

2007-09-21 16:09

 Depending on whether int_list is an abstract type or not then it's
either one or two bugs. From the reference manual on type class instances:

    The types in an instance declaration must not be abstract types which are
    elsewhere defined as equivalence types.

The same section also says that ground types like list(int) may not appear
in the head of an instance declaration. (IIRC from one of the Haskell papers
on this, then there is no particularly good reason for the latter restriction,
but I may be mistaken - it's been a months since I though much about type classes.)

For the current set of restrictions the implementation does admittedly not
do a good job reporting violations; given that we are intending to address
this as part of extending the type class system I'm not sure it's worth
putting too much effort into now.

~0000003

wangp (developer)

2007-09-21 17:06

 Am I right in thinking that this restriction won't be lifted any time soon? I've read the thread from earlier this year [1] and it sounds like a lot of work.

[1] http://www.mercury.cs.mu.oz.au/mailing-lists/mercury-developers/mercury-developers.200705/0022.html

~0000004

juliensf (administrator)

2007-09-21 17:15

 The key point in the that thread is the first one:

    (1) A language issue. Restrictions are necessary -- we need to choose a
    set of restrictions such that the type system is sound and (semi) decidable.
    It is one thing to suggest lifting individual restrictions, but the only
    way to design this is to consider the typeclass system as a whole.

Some of the proposed type class extensions are a lot of work; others are
relatively simple (allowing compound type like list(set(T)) in constraints
for example would happen as a result of fixing up the type-info being
packed into typeclass-info thing, you would get tabling of predicates with
type class methods into the bargain as well.)

I have been intending to work on this stuff all year; I just need to find a way
of making G12 disappear for a month or two.

~0000008

petdr (developer)

2007-10-03 14:17

 This compiler now detects this case.
+Notes

-Issue History
Date Modified Username Field Change
2007-09-21 15:48 wangp New Issue
2007-09-21 15:48 wangp File Added: eqv_instance.m
2007-09-21 16:09 juliensf Note Added: 0000002
2007-09-21 17:06 wangp Note Added: 0000003
2007-09-21 17:15 juliensf Note Added: 0000004
2007-09-25 11:53 juliensf Status new => assigned
2007-09-25 11:53 juliensf Assigned To => juliensf
2007-10-03 14:15 petdr Assigned To juliensf => petdr
2007-10-03 14:17 petdr Status assigned => resolved
2007-10-03 14:17 petdr Resolution open => fixed
2007-10-03 14:17 petdr Note Added: 0000008
+Issue History