Mercury Bugs - mercury
View Issue Details
0000002mercuryBugpublic2007-09-21 15:482007-10-03 14:17
Reporterwangp 
Assigned Topetdr 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
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? eqv_instance.m (180) 2007-09-21 15:48
https://bugs.mercurylang.org/file_download.php?file_id=2&type=bug

Notes
(0000002)
juliensf   
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   
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   
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   
2007-10-03 14:17   
This compiler now detects this case.

Issue History
2007-09-21 15:48wangpNew Issue
2007-09-21 15:48wangpFile Added: eqv_instance.m
2007-09-21 16:09juliensfNote Added: 0000002
2007-09-21 17:06wangpNote Added: 0000003
2007-09-21 17:15juliensfNote Added: 0000004
2007-09-25 11:53juliensfStatusnew => assigned
2007-09-25 11:53juliensfAssigned To => juliensf
2007-10-03 14:15petdrAssigned Tojuliensf => petdr
2007-10-03 14:17petdrStatusassigned => resolved
2007-10-03 14:17petdrResolutionopen => fixed
2007-10-03 14:17petdrNote Added: 0000008