Do notation considered harmful
From HaskellWiki
Contents |
1 Criticism
Haskell's do notation is popular and ubiquitous. However we shall not ignore that there are several problems. Here we like to shed some light on aspects you may not have thought about, so far.
1.1 Didactics
TheThis is wanted in order to simplify writing imperative style code fragments. The downsides are
- that, since notation is used almost everywhere, wheredotakes place, newcomers quickly believe that theIOnotation is necessary for doingdo,IO
- and that newcomers think, that is somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional.IO
These misunderstandings let people write clumsy code like
do putStrLn "text"
instead of
putStrLn "text"
or
do text <- getLine return text
instead of
getLineor
do text <- readFile "foo" writeFile "bar" text
instead of
readFile "foo" >>= writeFile "bar"
.
1.2 Library design
1.3 Safety
WithThe silent neglect of return values of functions. In an imperative language it is common to return an error code and provide the real work by side effects. In Haskell this cannot happen, because functions have no side effects. If you ignore the result of a Haskell function the function will even not be evaluated.
The situation is different forYou can write
do getLine putStrLn "text"
The same applies to
do System.cmd.system "echo foo >bar"
Is this behaviour wanted?
In safety oriented languages there are possibilities to explicitly ignore return values
(e.g. EVAL in Modula-3).
Haskell does not need this, because you can already write
do _ <- System.cmd.system "echo foo >bar" return ()
(>>) :: m () -> m a -> m a
2 See also
- Paul Hudak in Haskell-Cafe: A regressive view of support for imperative programming in Haskell
- Data.Syntaxfree on Wordpress: Do-notation considered harmful
