Re: [Caml-list] Operator overloading

[skaller <skaller@users.sourceforge.net>]

On Fri, 2007-03-09 at 17:28 +0100, Andreas Rossberg wrote:
> 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.

That depends on terminology. I was thinking in C++ terms:

	record = struct
	class = struct with methods

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

Yes, records can have state, but usually any functions stored
in record fields are not bound to the state of the record.
Methods of an object are bound to the state of the object.

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

Sure, but you're missing the point. In Haskell and in Oleg's Ocaml
implementation of typeclasses, a record object is like a C++ vtable.

A vtable contains static function pointers which can be
bound to the current object to create methods.

But I'm talking about replacing this with a class object,
so we're not talking about the methods binding against the
typeclass datatype .. we're talking about methods bound
against the typeclass itself.

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

I did. I said 'derived classes'.

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

Yes, its very weak. I don't know Haskell, but in Felix I have
typeclasses where I need to override the default method and I can't.

I don't know if Haskell suffers this restriction, but for someone
used to using C++ it shows the weakness of the 
typeclass/instance dichotomy  immediately. 
I actually need to do this:

typeclass container[bag,value] {
	virtual fold ..; // no default method
}

typeclass stl_container[bag,iterator,value] { 
   inherit container[bag,value]; // "implementation inheritance"
   fold .. // default method
}

because all STL containers have a single fold function,
implemented by using iterators. I need to instantiate
fold in the derived typeclass stl_container, but I'm
not allowed to.

So what I require is a tree:

	container --> stl_container --> vector --> vector<int>

and the distinction between typeclasses and instances is
a serious obstacle.

A C++ class has no such problems: you aren't limited to
defining an abstraction and one concrete instance class.

Roughly, my typeclasses allow adding new methods, but
you cannot override a method in a derived typeclass.

> Something like the covariance problem does not occur with type classes 
> (or modules, for that matter) because they decouple types from 
> interfaces. 

That's right.. it only occurs when you go up to the kind level.
Which occurs immediately if you want to try some dependent typing.
[I'm assuming a typeclass system with multiple type parameters
is required of course]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net