Re: [Caml-list] Operator overloading

[Andreas Rossberg <rossberg@ps.uni-sb.de>]

skaller wrote:
> 
> I'm sorry to write so poorly. This isn't the comparison I'm
> drawing. 
> 
> Consider *implementing* typeclasses with records,
> as in Oleg's Ocaml examples.
> 
> Ok, now replace the records with classes. Classes
> are more powerful because they provide
> 
> (a) state
> (b) inheritance etc

Records and classes are not in the same category. Records and *objects* 
are. OTOH, objects *are* basically records, except that they usually 
come with more expressive typing, particularly allowing recursive types 
and subtyping. State is still orthogonal - records can have state, too.

Classes are a mechanism for *creating* objects (and in weaker languages 
than OCaml, for defining subtyping relations). Take away inheritance and 
you are basically left with fancy syntax for a function creating a 
record of mutually recursive closures over some local variables.

> They also don't make the weak assumption of an 
> abstraction (possibly with default methods as in Haskell)
> and a single instantiation: in C++ at least you can
> have sequence of more derived classes.

Please distinguish subtyping and inheritance. Type classes can express 
something akin to nominal interface subtyping, e.g.

   class C a        where m1 :: t1
   class C a => D a where m2 :: t2

But it's true that they do only provide a very weak form of inheritance 
(via default methods).

> So the type model associated with this implementation
> can do more than the one just using plain records:
> records aren't typeclasses, so the class based implementation
> can't be compared with them:
> 
> 	records   		classes
> 	typeclasses		???????

I cannot make much sense of this diagram, because of the category 
mismatch I mentioned above.

> Anyhow my ARGUMENT was actually that using classes
> subsumes plain old records .. and classes are
> limited by the covariance problem, so records
> must be limited too.

Something like the covariance problem does not occur with type classes 
(or modules, for that matter) because they decouple types from 
interfaces. A type class is merely an interface, witnessed by a record, 
the actual type is abstracted out. With OO, this is mingled together (an 
object type *is* its interface), which produces that nasty recursion 
where all the type problems originate.

So the difference is in the way these features factorise abstraction, 
rather than in the intrinsic expressiveness of the underlying 
primitives. Operationally, you can view dictionaries as detached 
"vtables". This detachment allows them to be used in more flexible ways, 
and avoid nuisances like the binary method issue.

Of course, it also makes inheritance a rather alien concept.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de