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

[Tyson Richard DOWD]

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

What was that phase you and Tom use? `Blerk'?

-- 
       Tyson Dowd           # "Well, let's just say, 'if your VCR is
                            #  still blinking 12:00, you don't
     trd at cs.mu.oz.au        #  want Linux'". 
http://www.cs.mu.oz.au/~trd #  --Bruce Perens, Debian's Fearless Leader