[Haskell-beginners] Typeclasses vs. Data

[Thomas]

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 at vidplace.com
>
>