Browse thread
Operator overloading
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2007-03-09 (11:09) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] Operator overloading |
On Thu, 2007-03-08 at 23:36 -0800, oleg@pobox.com wrote: > John Skaller wrote: ``(Haskell does this little cheat .. it makes > typeclasses very easy to explain to OO people).'' Are you sure about > that? There has been many long and recurring threads on Haskell-Cafe > about typeclasses and OO classes. I think the common advice is _not_ > to think of Haskell typeclasses as of OO classes. Ralf Laemmel and I > once wanted to elaborate on the issue of OO in Haskell; we ended up > with a 79-page paper. I guess that shows that OO is never easy. Certainty requires at least a proof sketch, which I don't have. However I do have a 'gut feeling' :) It's hard to say, because in OO terms Haskell typeclasses are so weak it's surprising they're any use at all. If you consider your record implementation, observe it is just a weak special case of a C++ class. C++ classes can also provide state and inheritance. The state looks vaguely like dependent typing to me .. :) OK, so now we have a much more powerful model .. yet it has known limitations, in particular the so-called 'covariance' problem prevents OO from modelling any serious kind of system: for example a system with binary operators doesn't admit an OO representation. So all you need to do is elevate this model up one kinding level to see typeclasses, even with the additional power of 'everything C++ classes can do' are limited. Of course it is argument by analogy and intuition, not any kind of formal proof, that's for the experts :) Felix currently has multi-parameter typeclasses which use inlining because it's a whole program analyser, so it can, however explicit objects would be required either for separate compilation, or simply to experiment with the 'extra power' of dynamic binding. The 'obvious' implementation is of course a C++ class. The difference to ordinary use is that the object doesn't represent a type, but a typeclass, possibly with dependent type parameters: eg a 'get' method for an array with the length as a state variable. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net