[m-dev.] type classes --- thoughts?

[Fergus Henderson]

Tyson Richard DOWD wrote:
> 
> Haskell (or at least Hugs) allows you to define a type that `derives
> Eq', which means it defines equality using standard syntactic equality.
> If all `:- type' definitions were treated in this way, and another
> definition, say `:- sort' (*) defined types without this equality, you could
> have both normal, syntactic unification, and user-defined unification.

What happens with regard to import/export of the implicit
`type_class_instance' declarations?

Ada uses the term "limited type" for this sort of thing.

> Now, whether you want user-defined unification predicates is a little
> harder to decide - but in the context of a language with type-classes,
> their meaning is a little better defined - we simply assume that
> anything in class `unifiable' has `=' defined on it, which is usually
> the builtin unifier, but can be something else. 
>
> Because the typeclass system defines a source-to-source transformation
> (although it might not be implemented quite that way), the meaning of
> the program is well defined, and reasonably clear.

It's not that simple.

Unification can be invoked implicitly, without any explicit `=', which
makes it a bit different to ordinary typeclass methods.
On concrete types, unification is a polymorphically moded language
builtin; you can't replace it with a monomorphically moded
typeclass method.  Is the type class supposed to replace assignment
unifications?  Construction/deconstruction unifications?  
Complicated unifications?  Just in-in unifications?
Or just polymorphically typed in-in unifications??

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