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

[Fergus Henderson]

Tyson Richard DOWD, you wrote:
> 
> I assume you mean what is the `export_status' of the unseen
> `type_class_instance' that defines the unification method as the builtin
> unify. Well, I think this could be considered to have the same status as
> the definition of the type.

In that case, I think you want a way to explicitly derive the standard
typeclass instances, so that you can export a type as limited but
still use compare and unify in its implementation.

> > 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??
> 
> Yes. I hadn't realized this needed polymorphic modes. Is that all you
> need?

Well, no, it's worse than that -- since you want to take its address,
to put in a type_info, you need polymorphically moded higher-order terms.
This is difficult to do efficiently and difficult to do without
a very different execution model than the one that is used by the
current Mercury compiler.

Also, you run into problems with defining unification in a way
that is not infinitely recursive, because it is hard to avoid
using unification in your definition of unification.

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