[mercury-users] variable parameters in typeclass instances

[David Glen JEFFERY]

On 11-Nov-1999, Michael Day <mikeday at corplink.com.au> wrote:
> 
> Just a quick follow up to my previous message. As I think Ralph suggested,
> equivalent functionality to this:
> 
> :- typeclass container(C, T) <= arbitrary_constraint(T) where
> 	[
> 		pred insert(T, C(T), C(T)),
> 		mode insert(in, in, out) is det,
> 		...
> 	].
> 
> can simply be achieved by this:
> 
> :- typeclass container(C) where
> 	[
> 		pred insert(T, C(T), C(T)) <= arbitrary_constraint(T),
> 		mode insert(in, in, out) is det,
> 		...
> 	].
> 
> (Assuming support for constructor classes of course). Adding the arbitrary
> constraint to each predicate in the type class is a little dissatisfying
> but hardly a bar to such usage. 

In the case of the container type class, you probably don't want 
arbitrary_constraint(T) on the typeclass decl. Instead, there is likely to be
a constraint on some of the *instance* decls.

For example (ignoring our restriction on the form of types in an instance 
decls):

:- instance container(tree, T) <= ordered(T) where [
	...
].

:- instance container(hashtable, T) <= hashable(T) where [
	...
].

For a more thorough explanation of this, you might like to look up:

@inproceedings{spj96,
        author =        {Simon Peyton Jones},
        title =         {Bulk types with class},
        booktitle =     {Electronic Proceedings of the 1996 Glasgow Functional
                        Programming Workshop},
        year =          {1996},
        month =         {September},
        url =           {http://www.dcs.gla.ac.uk/fp/workshops/fpw96/Proceedings
96.html}
}

> I'm still wondering what it *means* for
> some of the predicates to have the constraint and some not, but it all
> seems to work. 

I'm not sure where you see the complication in the meaning. Those methods with
a constraint could only be called when the constraint is satisfied.

> I still think it would be nice to be able to specify
> universal type class instances, but it could be that I'm just wrong...

Well... if there is a `universal' instance of a class, then the methods of
the class don't really need to be methods; they could just be polymorphic
predicates.

However, there are plenty of examples where it would be nice
to be able to provide a `universal' instance as well as more specific 
instances. The problem here is that it does make the semantics (and probably
the implementation) rather more complicated because in these cases there may
be more than one instance declaration that could be applied (`overlapping'
instances). 

At this stage, I would say that it is very unlikely that we will allow 
overlapping instance declarations at any stage in the future.

There are, however, plenty of examples (including the container typeclass
above) where our current rules (ie. requiring the types in an instance decl
to have a bound top-level constructor with variables as arguments) are not
sufficient to express things that we really should be able to express. Our
current design is deliberately conservative in trying to avoid overlapping
instances.

It is quite likely that we will change these rules at some stage in the future
(as soon as we can figure out another decent set of rules that avoids
overlapping instances).



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