[m-dev.] type class constraints

[Fergus Henderson]

On 21-Dec-1999, David Glen JEFFERY <dgj at cs.mu.OZ.AU> wrote:
> On 20-Dec-1999, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 15-Dec-1999, Michael Day <mcda at cat.cs.mu.OZ.AU> wrote:
> > > :- pred snort(T, T) <= is_funky(T, char).
> > > 
> > > This will be flagged as an error by the compiler, stating that such
> > > constraints are not implemented. Will they be implemented and if so, when?
> > > The lack of them appears to make multiple parameter type classes less
> > > useful than they would otherwise be.
> > 
> > I don't quite recall our rationale for not supporting that.
> > DJ, do you remember?  What would happen if we were to just
> > uncomment that check?
> 
> I'm pretty sure that either the RTTI that gets generated would be wrong or the
> compiler would barf when generating the RTTI. 

Ah, yes, the reason for the restriction is that currently
the RTTI representation of the position of a type_info variable
only allows it to be in a field of a typeclass_info, not
in a field of a field of a typeclass_info, as would be required
for e.g.

	:- pred foo(T) <= bar(list(T)).

But Michael Day's example should work fine.
The RTTI problem only arises for other examples, like the one above.
We could fairly easily relax the restriction to allow type class
constraints on predicates to have any form in which the type
variables occur only as arguments of a top-level type class constraint.
That would be slightly more general than the current restriction,
which requires all arguments of a class constraint to be type variables.

However, there would still be examples for which the restrictions
imposed by the current RTTI format would be a problem.  In the long
run we should change the RTTI format.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------