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

[Zoltan Somogyi]

> I'm really not sure about univ, though. Thoughts, anyone?

I think univ should be like Ada's limited private; only permitted operation
is assign (and univ_to_type of course).

> I think, however, that what I favour is to have two builtin classes: unifiable
> and comparable.

The two are related: in-in unification is comparison followed by a check
that the comparison returned =.

> Everything is assumed to belong to them, except where the
> type is abstract and an explicit declaration is made to the contrary. 

It would be nice if could do away with the runtime error in the unifications
we generate for higher-order thingies. This would mean that defining an
abstract type and not saying that its is not unifiable and then (in the
module body) giving a definition that includes highy-order components
is an error.


>     :- type non_canonical_set(T).
>     :- nonunifiable(non_canonical_set(T)).

Any such thing should have one declaration, not two.

> in some modes, unification will not be needed for some
> preds, but it will be needed for others. Should we allow contexts to be added
> on a mode-by-mode basis? I think not, but it may be useful.

I think we should not allow this.

> > 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.
> 
> Well... surely this is just the same as how we handle polymorphic output args
> at the moment - the typeinfo is always input (and with type classes, if there
> is a type class constraint on the type variable, then the appropriate
> dictionary
> is passed as well). Am I missing something, or did I just word it badly?

One might want a predicate such as set__init to take an argument specifing
which kind of set implementation I want (unordlist, ordlist, bintree, rbtree,
tree234 etc). The return value would be an empty set, and its type would be
a member of the set type class, but you can't know in advance what the typeinfo
will be.

This is a bad example of the use of the capability that Fergus is (I think)
talking about, since it would be better to simply require programmers
to call bintree_set:init or tree234_set:init. The reason it is better
is because it avoid "control coupling" as defined by Steve McConnell,
(see, writing 252 lecture notes is good for something ;-). Are there
any better examples?

Zoltan.