

Haskell : polymorphism at value level, not method parameter level - gtani
http://chrisdone.com/posts/2011-10-16-value-polymorphism.html

======
macrael
I haven't done much Haskell programming, but this feels a little dirty to me.
Can other Haskell coders chime in and tell me if this is good practice? It
does seem cool to have functions return different values depending on what you
ask for, but especially as a parser it seems like it would be fragile.

~~~
tel
There's not really a line between parameters and values in Haskell. Static
values can just be thought of as constant, zero-arity functions. The heart of
this is, to me, more generally thought of as polymorphism on the return type.

Read is a great example of this working very well. It's, as you say, not
really robust enough to work at the API or program level, but Show/Read
provides a pretty quick, everywhere available serialization for many values.
It's vital for debugging at the REPL.

Probably the most notorious example is the newbie-killer Regex library which
uses polymorphic return types to dispatch what kind of result you want from
your match, such as the match index or a list of group matches. It seems
really clever since you just call the match function and affect whatever kind
of pattern matching you want in order to pull values out, but it has always
smelled to me since it's very hard to discover the functionality — the
polymorphic return types aren't opaque, but are burdensome — and seems quite a
bit too magical.

So I wouldn't personally go wild with return type polymorphism. It's obviously
necessary in order to write things like filter, but unless the return type is
simple and easily inferred by both compilers and people it can get hairy fast.

~~~
Miky
Thinking of values as functions is more misleading than it is illuminating.
There are values that are functions, and there are values that are not, and
the type system is extremely clear about which are which. It's just that all
values can be polymorphic, including functions.

Conal Elliott has a good blog post about it.
[http://conal.net/blog/posts/everything-is-a-function-in-
hask...](http://conal.net/blog/posts/everything-is-a-function-in-haskell)

~~~
tel
True. It's most accurate to think of functions as values which are of the type
(a -> b) "mappings".

But really it's all confusion deriving from the fact that functions in Haskell
mean something completely different from other languages.

