in ,

Do Notation Considered Harmful, Hacker News


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.


The do notation hides functional details. This is wanted in order to simplify writing imperative style code fragments. The downsides are that:

do notation is used almost everywhere IO takes place, newcomers quickly believe that the do notation is necessary for doing IO ,

    Newcomers might think that IO is somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional,

      Newcomers might think that the order of statements determines the order of execution.

      These misunderstandings let people write clumsy code like

      instead of


      do text

      getLine     return text

      instead of


      do    text readFile foo    writeFile "bar" text

      instead of

      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



      (7)     return ( (x - y



      5 and (5) 7 can be evaluated in any order, also in parallel. Or consider

      do x

      Just 3 ( 5     y     return

      ( (x - y



      5 is probably not evaluated at all, because its result is not necessary to find out that the entire

      do ) describes a Nothing .

      Library design

      Unfortunately, the 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 in principle has nothing to do with a monad . All "put" operations have the monadic result


      . In fact it is a (Writer monad using the ) Builder type, and all you need is just the Builder monoid. Even more unfortunate, the applicative functors were introduced to Haskell's standard libraries only after monads and arrows , thus many types are instances of Monad and Arrow classes, but not as many are instances of Applicative . There is no 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



      Header get get


      (Not using monads, along with the ) 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           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 (Reader monad, where we call (local on an incremented counter for each generated identifier. Alternatively you can view it as
      Continuation monad.

      (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) -> (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 way users cannot accidentally place a return somewhere in a

        block where it has no effect.


      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.


      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 not even be evaluated. The situation is different for

      IO 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 getLine . The same applies to

      do System


      Cmd ( system “echo foo> bar”

      where you ignore the ExitCode . Is this behavior wanted?

      There are possibilities to explicitly ignore return values ​​in safety oriented languages (eg EVAL (in) Modula-3

      ). Haskell does not need this, because you can already write do _

      System . Cmd system “echo foo> bar”     return


      Writing _ 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 do notation. 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 () .

      New developments:

        GHC since version 6. 19 emits a warning when you silently ignore a return value

          There is a new function called void that makes ignoring of return values ​​explicit: (GHC ticket)

    • Happy with less sugar

      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 MonadPlus , because there is no mzero

        (it would be an empty list of events, but their probabilities do not sum up to 1) and mplus is not associative because we have to normalize the sum of probabilities to 1. Thus we cannot use standard ) guard

          for this monad. However we would like to write the following:

    • do f family     guard ( existsBoy f )     return f

      Given a custom combinator which performs a filtering with subsequent normalization called ( >>=? ) : Distribution a -> ( a -> Bool

        (Distribution a we can rewrite this easily:

      Note that the ( >>=? ) combinator introduces the risk of returning an invalid distribution (empty list of events), but it seems that we have to live with that problem.

      Alternative combinators

      If you are used to writing monadic functions using infix combinators ( ) and ( >>= 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 Monad type constructor class, where the monadic result type cannot be constrained. This is e.g. useful for the Set data type , where the element type must have a total order.

      Useful applications

      It shall be mentioned that the do sometimes takes the burden away from you of writing boring things. E.g. in

      getRight :: Either a b -> Maybe b getRight y =     do Right (x y        return x

      a case on is included, which calls fail if

      is not a Right ( ie Left ), and thus returns Nothing in this case.

      Also the mdo notation proves useful , since it maintains a set of variables for you in a safe manner. Compare

      mdo x f x y z      y x y z      z x y z      return ( (x y (z) )


      mfix     ( ~ ( ~ ( x , , z ), _ ) ->        do x f x (y (z)           y x y z           z x y z           return (( (x ,

      y , (z) ),

      x y z ))

      See also

What do you think?

Leave a Reply

Your email address will not be published.

GIPHY App Key not set. Please check settings

Google Stadia 'Connect' Succeeds at Failing to Flatter Gamers – Again, Crypto Coins News

Google Stadia 'Connect' Succeeds at Failing to Flatter Gamers – Again, Crypto Coins News

Ripple CTO kicked off YouTube a week after lawsuit