|
Notes |
|
|
|
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
|
|
|
|
|
|
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. |
|
eqv_instance.m (180) 2007-09-21 15:48