A concept in Haskell which is particularly novel is that polymorphism works at the value level rather than function-parameter or object-dereference level.
Function-parameter polymorphism comes in some different forms, for example, C++:
Function overloading is a type of function-parameter polymorphism. Generic functions in Common Lisp are another way to have function-parameter polymorphism:
Object-dereference (or message passing) polymorphism is common to most object oriented languages. Depending on the object, the function/message will do something different:
To avoid confusion, Haskell also has function parameter polymorphism, like C++ and Common Lisp above:
But more generally, Haskell has value polymorphism, which is that any value can be polymorphic and will be instantiated to a class instance depending on type signature or annotation:
The type of an expression
def therefore is
Default a => a, or, “any instance of
Default”. I can instantiate an instance myself by specifying a type signature:
Or by type inference, meaning that the combination of this expression with other expressions allows the compiler to infer the single correct type instance:
But with no information it will be a static compile error:
λ> def Ambiguous type variable `a' in the constraint: `Default a' arising from a use of `def' at <interactive>:1:0-2 Probable fix: add a type signature that fixes these type variable(s)
Why is value polymorphism beneficial? Some trivial examples follow (and you are trusted to extrapolate to the more sophisticated things that might otherwise obscure the essence of this feature).
Read class contains a method
read which is polymorphic on the return value:
It parses a data type from a string. Combined with the
Show class, together
Show make a naive serialization library. In the same way, it would be ambiguous to read without specifying the instance:
λ> read "2" Ambiguous type variable `a' in the constraint: `Read a' arising from a use of `read' at <interactive>:1:0-7 Probable fix: add a type signature that fixes these type variable(s)
But specifying with a type signature or using type inference are fine:
Another example is JSON parsing (the real class is different to this, but introduces questions that are irrelevant to the point of this post).
decode function is return-value polymorphic, it can be read like this:
That is, it returns a result (success or fail) with a value which is an instance of the JSON class.
So both specifying an instance or using inference works:
And it works however complex you want to go with your types:
Thus by merely specifying the return type we have effectively generated a parser. An invalid string will produce an error:
In fact, the literal
1 is also polymorphic with type
Num a => a, meaning that the number could be an
Rational, or a user-defined type like
Scientific. It will be determined by inference or annotation.
The list goes on. More examples include database query results, string literals, monoids, monads, …
Default class is a real class and in common use today.