[Haskell-beginners] Type classes are not like interfaces, after all

[Francesco Bochicchio]

2009/1/23 Paul Visschers <mail at paulvisschers.net>

>  Hello,
>
> It seems like you have some trouble with grasping the concept of
> polymorphism in this particular case.
>
> <...>
>

I think I get the polymorphism. What I don't get is why a specialized type
cannot
replace a more generic type, since the specialized type implements the
interface
defined in the generic type.

As I tried to explain, I'm probably misled by the comparison with  OOP
languages, where polymorphism is implemented via interfaces (Java) or
abstract classes/methods (C++). For instance in Java you can write:

AbstractInterface a = new ConcreteClass();

if ConcreteClass implements AbstractInterface. The complier will handle a as
an instance of AbstractInterface, ignoring
anything that is not specifed in its declaration. This make the substitution
safe: for instance calling
a.AbstractInterfaceMethod() is fine, while calling a.ConcreteClassMethod()
gives you an error.


Now, I understand that this is not the case in haskell, and I understand the
formal reason you give for this.
What I am trying to understand is the _actual_ reason behind the formal
reason: usually a programming language place
limits to avoid ambiguity or misuse of language feature.

<...>

The problem comes from the extra type annotation:
a = 3 :: Integer
Which says that instead of being of any numeric type, a is of type
Integer. This is less general, since you can't use it when you need an
Int or a Double for example.

This is what I don't get : why yielding an Integer is not  good enough for a
function
that promises to yield a num?  What is missing in Integer?


>
>
> I hope I explained it clearly. If not please reply.
>
> Paul
>

You have been clear. I'm probably still too bound to OOP world. Thanks.


Ciao
-------
FB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20090123/afac5e0d/attachment.htm