Difference between revisions of "Do notation considered harmful"
(applicative functors; mdo notation)
|Line 61:||Line 61:|
=== Safety ===
=== Safety ===
Revision as of 11:55, 5 November 2007
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.
do notation hides functional details.
This is wanted in order to simplify writing imperative style code fragments.
The downsides are
- that, since
donotation is used almost everywhere, where
IOtakes place, newcomers quickly believe that the
donotation is necessary for doing
- and that newcomers think, that
IOis somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional.
These misunderstandings let people write clumsy code like
do putStrLn "text"
do text <- getLine return text
do text <- readFile "foo" writeFile "bar" text
readFile "foo" >>= writeFile "bar"
do notation is so popular that people write more things with monads than necessary.
See for instance the Binary package.
It contains the
Put monad, which has in principle nothing to do with a monad.
Even more unfortunate,
the applicative functors were introduced to Haskell's standard libraries only after monads and arrows,
thus many types are instances of
but not as much are instances of
There is not special syntax for applicative functors because it is hardly necessary.
You just write
data Header = Header Char Int Bool readHeader :: Get Header readHeader = liftA3 Header get get get
Not using monads and thus
do notation can have advantages.
Consider a generator of unique identifiers.
First you might think of a
State monad which increments a counter each time an identifier is requested.
run :: State Int a -> a run m = evalState m 0 newId :: State Int Int newId = do n <- get modify succ return n example :: (Int -> Int -> a) -> a example f = run $ do x <- newId y <- newId return (f x y)
do notation we have kept alive a dark side of the C programming language:
The 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 for
While processing the
IO you might still ignore the contained return value.
You can write
do getLine putStrLn "text"
and thus silently ignore the result of
The same applies to
do System.cmd.system "echo foo >bar"
where you ignore the
Is this behaviour wanted?
In safety oriented languages there are possibilities to explicitly ignore return values
EVAL in Modula-3).
Haskell does not need this, because you can already write
do _ <- System.cmd.system "echo foo >bar" return ()
_ <- should always make you cautious whether ignoring the result is the right thing to do.
The possibility for silently ignoring monadic return values is not entirely the fault of the
It would suffice to restrict the type of the
(>>) combinator to
(>>) :: m () -> m a -> m a
This way, you can omit
_ <- only if the monadic return value has type
It shall be mentioned that the
do sometimes takes the burden from you to write boring things.
getRight :: Either a b -> Maybe b getRight y = do Right x <- y return x
y is included,
y is not a
and thus returns
Nothing in this case.
mdo notation proves useful, since it maintains a set of variables for you in a safe manner.
mdo x <- f x y z y <- g x y z z <- h x y z return (x+y+z)
mfix (\ ~( ~(x,y,z), _) -> do x <- f x y z y <- g x y z z <- h x y z return ((x,y,z),x+y+z))
- Paul Hudak in Haskell-Cafe: A regressive view of support for imperative programming in Haskell
- Data.Syntaxfree on Wordpress: Do-notation considered harmful
- Things to avoid#do notation