[mercury-users] constructor class syntax

[David Glen JEFFERY]

On 03-Nov-1999, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 02-Nov-1999, Michael Day <mikeday at corplink.com.au> wrote:
> > 
> > making the assumption that Mercury will have support for constructor
> > classes in the not impossibly distant future, would it be reasonable to
> > expect syntax roughly like this:
> > 
> > :- class mappable(F(T)) where
> > 	[
> > 		pred map(pred(X, Y), F(A), F(B)),
> > 		mode map(in, in, out) is det
> > 	].
> > 
> > :- instance mappable(list(T)) where
> > 	[
> > 		pred(map/3) is list__map
> > 	].
> 
> With the exception of the `F(T)' part and the use of `:- class' rather
> than `:- typeclass', that looks reasonable to me at first glance.
> But you have probably spent more time thinking about this than any of
> the rest of us.

I think Michael probably wants to say:

:- class mappable(F) where
[
	pred map(pred(A, B), F(A), F(B)),
	mode map(in, in, out) is det
].

:- instance mappable(list) where
[
	pred(map/3) is list__map
].

It is a subtle but fairly important distinction; one way to understand it is
that your type class method is effectively a predicate:
	:- pred map(pred(A, B), F(A), F(B)) <= mappable(F).

the corresponding pred from Michael's mappable(F(T)) declaration above would
be:

	:- pred map(pred(A, B), F(A), F(B)) <= mappable(F(T)).

which looks more than a little dodgy.

> However, I still think the declaration should be `:- typeclass'
> rather than `:- class'.  The Haskell `class' declaration often
> confuses beginners, who think it declares a class of objects,
> i.e. a type, rather than declaring a class of types.
> This is particularly common amongst people who have learnt C++ or Java
> first ;-).  The `:- typeclass' notation emphases that the concept is
> quite different from C++ or Java classes.

Agreed.

> > I can't see any use of expressing constraints on T, at this point. Would
> > it in fact be desirable to rephrase the declaration as:
> > 
> > :- class mappable(F/1) ...
> 
> Yes, that makes more sense.  Or we could perhaps take the Haskell
> approach of inferring the kind from the context, and just use the
> syntax `:- typeclass mappable(F)', with the arity being inferred
> from the occurrences of `F(A)' and `F(B)' in the body.

Indeed... inferring the kind is pretty simple. 

I can see one argument for requiring explicit kind annotations, though: abstract
typeclass declarations. We may like to allow declarations of the form:

:- typeclass c(T).

which would declare the existence of a typeclass, presumably in the interface
of a module, but would not allow anyone (other those with access to the
module implementation section) to provide instances. Anyhow, the point is that
it is not clear from the declaration of c/1 above what the kind of T is meant
to be. Perhaps we should require the kind of every type class argument to
be explicitly provided, unless it is of kind 0 (ie. a type).

I guess the same holds for type classes without any methods too...


dgj
-- 
David Jeffery (dgj at cs.mu.oz.au) | If your thesis is utterly vacuous
PhD student,                    | Use first-order predicate calculus.
Dept. of Comp. Sci. & Soft. Eng.|     With sufficient formality
The University of Melbourne     |     The sheerist banality
Australia                       | Will be hailed by the critics: "Miraculous!"
                                |     -- Anon.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------