|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000002||mercury||Bug||public||2007-09-21 15:48||2007-10-03 14:17|
|Target Version||Fixed in Version|
|Summary||0000002: equivalence types in instance declarations|
|Description||mmc 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.
|Tags||No tags attached.|
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.
Am I right in thinking that this restriction won't be lifted any time soon? I've read the thread from earlier this year  and it sounds like a lot of work.
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.
|This compiler now detects this case.|
|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|
||Assigned To||juliensf => petdr|
||Status||assigned => resolved|
||Resolution||open => fixed|
||Note Added: 0000008|