[m-dev.] type classes --- thoughts?
Tyson Richard DOWD
trd at hydra.cs.mu.oz.au
Wed Mar 12 15:41:17 AEDT 1997
> 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
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
More information about the developers