[Haskell-beginners] Type classes are not like interfaces, after
bieffe62 at gmail.com
Fri Jan 23 08:37:12 EST 2009
2009/1/23 Paul Visschers <mail at paulvisschers.net>
> 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
replace a more generic type, since the specialized type implements the
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
that promises to yield a num? What is missing in Integer?
> I hope I explained it clearly. If not please reply.
You have been clear. I'm probably still too bound to OOP world. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners