Hello! I think the pieces all start to fall into place. :-) I still haven't truly understood typeclasses, but at least I see progress in my understanding. The analogy between OO-interfaces and typeclasses seems to be a bit misleading here, though. Because IIUC then in Haskell typeclasses are not a substitute for a type - a misconception that bit me here, while in (at least the OO-languages I use) interfaces can usually be used instead of types (except object creation & assignment). For example: if n < 0 then (k :: X) else (BeginCont k (n-1) :: BeginCont X) does not type check in Haskell. The "equivalent" construct would type check in OO(*) - although I understand that this does not mean the same in OO as in Haskell. Probably type classes are really orthogonal to types as David writes. But then I would consider them as rather different from interfaces in OO, too. Well, the Haskell road is still long for me, but it's real fun travelling... ;-) Thank you, everybody! Thomas PS: *) class BeginCont : public InterfaceX ... if(n < 0) { k; // type is: InterfaceX* } else { new BeginCont(k, (n - 1)); // type is: BeginCont* ~= InterfaceX* } Ok, the type check is trivial (essentially a NOOP) in the code above, but it would even type check as: CallWithInterfaceX((n<0)?k:new BeginCont(k, n-1)); which is rather close to the Haskell code semantically. On 21.07.2011 15:24, David Place wrote:
On Jul 21, 2011, at 9:09 AM, Felipe Almeida Lessa wrote:
It is less polymorphic because 'k' has a rigid, defined type. Its type was chosen by the one who called the function. He gave you some 'k' that satisfy the class constraint, but you don't know which one.
I think that Thomas made an interesting step in his first post that may explain the problem. First, he created a type that had (or would eventually have had) constructors for each of the different kinds of continuations. This type is proper type in the mind of the type inference algorithm. Then, in the interest of modularity, he substituted a class for the type. The class is not a proper type, so the substitution doesn't work.
I remember going through this same confusion coming from a more object-oriented way of thinking. A class in Haskell is more like an interface or a protocol in object-oriented languages. I think of it as an orthogonal construct to type.
____________________ David Place Owner, Panpipes Ho! LLC http://panpipesho.com d@vidplace.com