[m-dev.] Existentially quantified data constructors

[Julien Fischer]

On Wed, 16 Apr 2008, Ralph Becket wrote:

> Mark Brown, Tuesday, 15 April 2008:
>> The fact that you are required to use `=>' rather than `<=' is meant to
>> be a hint that you are specifying one kind of constraint over another.
>> Perhaps it isn't strong enough, but the error message *does* try to draw
>> your attention to this.  It's also covered in section 11.2 of the reference
>> manual.
>
> I'm not saying the Reference Manual is unclear, just that it tells you
> what, not why.  Perhaps the problem is just with me, but I reckon I'm not
> alone: the picture I have when I'm programming is that a type class
> specifies an interface implemented by a vector of types.  Where things
> start to get fuzzy is with the restrictions.  I remember a certain list
> of "do"s and "don't"s


> (don't use equivalence types in instance declarations,

There is no such restriction, perhaps this was the one you were
referring to?

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

> don't repeat variables in instance declarations, instance
> variable arguments must be of the form typector(typevar, typevar, ...),

The reference manual already gives the reasons for these restrictions,
from section 10.2

 	These restrictions ensure that there are no overlapping instance
 	declarations, i.e. for each typeclass there is at most one instance
 	declaration that may be applied to any type (or sequence of types).

> don't mix existentially and universally quantified variables in the same
> constraint, etc.),

As Mark has alredy pointed out, this wouldn't work with our
implementation of RTTI.

> but I'm damned if I can remember why any of those
> restrictions are necessary. 
>
> It would be Very Helpful if for each
> restriction we could provide a simple example somewhere of *why*
> violating it leads to ambiguity/unsoundness/madness/divorce.

Ok, overlapping instances are bad because the implementation won't
know what method to call.  The fourth case you list would presumably
result in C code that wouldn't compile or something along those
lines (assuming it gets through the rest of the compiler at all.)

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------