Computer Science, Mathematics, Society, Relationships, Sex, 0xf00d, Pets, Leashes and Secretaries.
Saturday, March 08, 2008
Why I don't use Haskell for Functional Programming
When designing programming languages, the hard choice is not about
what you put into the language -- it is what you leave out or what is
mutually exclusive. Haskell did make the choice of being a purely
functional programming language and they did the choice of being
lazy. The positive things manifesting from this is: Lazy evaluation
finds more normal forms than strict evaluation. In the simply typed
lambda calculus it finds all of them but I am not sure this is
the case in Haskell. Secondly, since the language is pure the compiler
is free to reorder computations as it sees fit. Languages which are
strict have an evaluation order limiting how we can reorder
terms. Standard ML is extremely limiting in this respect due to the
correct handling of IEEE floating point numbers and that arithmetic
overflow must throw exceptions.
It is possible to have a strict functional language with added
references and exceptions. These effects can, without too much hassle,
be added to the language in a way such that the implications are
minimal. Ocaml and Standard ML are the main examples, I believe. We
all know that Haskell took the monad route to add effects. A heavy
inspiration from Category Theory gave them a tool to build in effects
by encoding them as monads. It should be noted that there are other
ways to add effects into a purely lazy functional language as is shown
by Clean.
I don't like monads for programming effects. Granted, they give me a
way to formalize (in the type) what effectful computations a given
function have and that can be a tremendous help. But on the other
hand, it also forces me to lift computations into the monad as soon as
I bring it into play. First of all, the lifting adds a lot of boilerplate
code. If I need a monad transformer, this quickly gets out of hand: My
code tends to be invocation of the correct lifts into the
monads. Second, as effects can alter control flow, there is often the
requirement of doing global changes to the program. The changes are
not limited to the function using the effect only - the infection
spreads to the callers and often further up the call chain.
And SML is not perfect at all too: We have a lot of old cosmetic
changes we ought to do. And we better get a grip on how to add linear
typing and an effect system so we can reap the benefits that monads
does give you without all of the hassle.
Subscribe to:
Post Comments (Atom)
About Me
- Jesper Louis Andersen
- Lambda-loving CS Geek. Likes metal music. Likes dogs, cats. Does not like pictures of dogs and cats (unless they are lambdacats!)Has an unhealthy coffee addiction. Calls himself the coffee zombie in the morning (BEEEEANS!)Has a neverending curiosity gene, loves intelligence and passion.