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

[Tyson Richard DOWD]

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

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.

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

Here's a definition of `limited type' I found (for Ada):

   A limited type is a private type that has no implicit operations.  In
   other words, you must declare all of the operations associated with a
   limited type. Because assignment is not an implicit operation for
   limited types, you cannot use limited types in all situations.

The definition seems to fit the usage ok - perhaps `:- limited_type'
would be a better declaration then.

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

Yes. I hadn't realized this needed polymorphic modes. Is that all you
need? I suppose a polymorphically moded typeclass method will
just be defined in terms of polymorphically moded language builtins,
and other polymorphically moded predicates, so is this the only
stumbling block? 

What I mean is, would this work if we had polymorphic modes?  Secondly,
if it did work, would it be worth it? I can see it would be useful in
some situations, but in general would it make programming easier, or
just add opportunities for confusion? 

I think it is (initially) more important to have user-defined methods
for `compare' than `unify', and I suspect this will be a little simpler.

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