[m-dev.] Existentially quantified data constructors

Ralph Becket rafe at csse.unimelb.edu.au
Wed Apr 16 13:46:37 AEST 2008

Julien Fischer, Wednesday, 16 April 2008:
> >(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.

Yes, that's the one.

> >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).

Is this a necessary restriction or an artefact of our implementation?
Why isn't this rule relaxed with functional dependencies?

> >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.)

Thanks for the explanation.
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

More information about the developers mailing list