Do notation considered harmful
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.
This is wanted in order to simplify writing imperative style code fragments. The downsides are that:
- Since notation is used almost everywheredotakes place, newcomers quickly believe that theIOnotation is necessary for doingdo,IO
- Newcomers might think that is somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional,IO
- Newcomers might think that the order of statements determines the order of execution.
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"
The order of statements is also not the criterion for the evaluation order. Also here only the data dependencies count. See for instance
do x <- Just (3+5) y <- Just (5*7) return (x-y)
do x <- Just (3+5) y <- Nothing return (x-y)
1.2 Library designUnfortunately, the
You just write
data Header = Header Char Int Bool readHeader :: Get Header readHeader = liftA3 Header get get get
readHeader = Header <$> get <*> get <*> get
Not using monads, along with the
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)
If you are confident, that you will not need the counter state at the end and that you will not combine blocks of code using the counter (where the second block needs the state at the end of the first block),you can enforce a more strict scheme of usage. The following is like a
newtype T a = T (Int -> a) run :: T a -> a run (T f) = f 0 newId :: (Int -> T a) -> T a newId f = T $ \i -> case f i of T g -> g (succ i) example :: (Int -> Int -> T a) -> a example f = run $ newId $ \a -> newId $ \b -> f a b
- This page addresses an aspect of Haskell style, which is to some extent a matter of taste. Just pick what you find appropriate for you and ignore the rest.
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 not even be evaluated.The situation is different for
You can write
do getLine putStrLn "text"
The same applies to
do System.Cmd.system "echo foo >bar"
Is this behaviour wanted?
There are possibilities to explicitly ignore return values in safety oriented languages
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
- GHC since version 6.12 emits a warning when you silently ignore a return value
- There is a new function called that makes ignoring of return values explicit: GHC ticket 3292void
2 Happy with less sugar
2.1 Additional combinators
Using the infix combinators for writing functions simplifies the addition of new combinators. Consider for instance a monad for random distributions.This monad cannot be an instance of
However we would like to write the following:
do f <- family guard (existsBoy f) return f
we can rewrite this easily:
family >>=? existsBoy
but it seems that we have to live with that problem.
2.2 Alternative combinatorsIf you are used to writing monadic functions using infix combinators
you can easily switch to a different set of combinators.This is useful when there is a monadic structure that does not fit into the current
This is e.g. useful for the Set data type, where the element type must have a total order.
3 Useful applicationsIt shall be mentioned that the
getRight :: Either a b -> Maybe b getRight y = do Right x <- y return x
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))
4 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
- Things to avoid#do notation