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

[Fergus Henderson]

David Glen JEFFERY, you wrote:
> 
> I've been giving some thought to adding type classes (a la Haskell) to
> Mercury. I thought I'd see what you guys think of it.

Well, we could spend a lot of time debating the syntax...
so I'll restrict myself to commenting on just a few issues.

The big one: what about type checking and type inference?

> 	:- type_class foo(T) where
> 		pred a(T::out) is det,
> 		pred b(T::in, T::in, T::out) is det,
> 		pred c(T::in, T::in, T::out) is semidet,
> 		func d = T::out is det.

Can you have preds with multiple modes?
Must every class method have `T' somewhere in its type signature?
Can you have preds which are polymorphic on types other than `T',
or in addition to `T'?

> One important point which applies to type classes for logic programs in
> general is the restriction of equality (unification) to a certain typeclass.
> (cf. Haskell's `Eq' class).  We really can't take the same approach as
> Haskell/Gofer here, since we can't require the user to provide equality
> predicates for all types which are allowed to be compared.

The situation seems more similar to Haskell's `Eval' class;
in Haskell, all user-defined types are implicitly defined as
instances of `Eval'.

As for declaring things to be non-unifiable/non-comparable,
given that unify/2 and compare/3 can be implemented using arg and functor,
you'd better make such things non-arg-able and non-functor-able too.
Oh, and what about type_to_univ and univ_to_type -- should univ
be unifiable?

Well, that's a nice little can of worms there...

> As far as implementation goes, a field should probably be added to the
> type-info which contains a `dictionary' of methods for each type class that
> a type belongs to. (The dictionary is basically an array of code pointers for
> each pred/func in the interface of a typeclass).
> 
> When calling a pred/func which has a typeclass constraint in its declaration, 
> the appropriate dictionary is placed as an extra argument to the pred, much
> in the same way as type-infos become extra arguments.

Hmmm, so the type-infos are always input to the procedure, even for output
arguments, or for a function's return value... that does seem a bit limiting.

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