# Do notation considered harmful

### From HaskellWiki

(GHC-6.12 warns about silent return value ignorance) |
m (fix typo) |
||

(6 intermediate revisions by 5 users not shown) | |||

Line 1: | Line 1: | ||

== Criticism == | == Criticism == | ||

− | Haskell's [[do notation]] is popular and ubiquitous. | + | Haskell's [[Keywords#do | do notation]] is popular and ubiquitous. |

However we shall not ignore that there are several problems. | 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. | Here we like to shed some light on aspects you may not have thought about, so far. | ||

Line 9: | Line 9: | ||

The <hask>do</hask> notation hides functional details. | The <hask>do</hask> notation hides functional details. | ||

This is wanted in order to simplify writing imperative style code fragments. | This is wanted in order to simplify writing imperative style code fragments. | ||

− | The downsides are | + | The downsides are that: |

− | * | + | * Since <hask>do</hask> notation is used almost everywhere <hask>IO</hask> takes place, newcomers quickly believe that the <hask>do</hask> notation is necessary for doing <hask>IO</hask>, |

− | * | + | * Newcomers might think that <hask>IO</hask> 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 | These misunderstandings let people write clumsy code like | ||

Line 64: | Line 64: | ||

=== Library design === | === Library design === | ||

− | Unfortunately, the <hask>do</hask> notation is so popular that people write more things with monads than necessary. | + | Unfortunately, the <hask>do</hask> notation is so popular that people write more things with monads than necessary. See for instance the [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.4.1 Binary] package. It contains the <hask>Put</hask> monad, which in principle [http://www.haskell.org/pipermail/haskell-cafe/2009-January/053317.html has nothing to do with a monad]. |

− | See for instance the [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.4.1 Binary] package. | + | |

− | It contains the <hask>Put</hask> monad, which | + | |

All "put" operations have the monadic result <hask>()</hask>. | All "put" operations have the monadic result <hask>()</hask>. | ||

In fact it is a <hask>Writer</hask> monad using the <hask>Builder</hask> type, and all you need is just the <hask>Builder</hask> monoid. | In fact it is a <hask>Writer</hask> monad using the <hask>Builder</hask> type, and all you need is just the <hask>Builder</hask> monoid. | ||

− | Even more unfortunate, | + | Even more unfortunate, the [[applicative functor]]s were introduced to Haskell's standard libraries only after [[monad]]s and [[arrow]]s, thus many types are instances of <hask>Monad</hask> and <hask>Arrow</hask> classes, but not as many are instances of <hask>Applicative</hask>. There is no special syntax for applicative functors because it is hardly necessary. |

− | the [[applicative functor]]s were introduced to Haskell's standard libraries only after [[monad]]s and [[arrow]]s, | + | |

− | thus many types are instances of <hask>Monad</hask> and <hask>Arrow</hask> classes, | + | |

− | but not as | + | |

− | There is no special syntax for applicative functors because it is hardly necessary. | + | |

You just write | You just write | ||

<haskell> | <haskell> | ||

− | data Header = Header Char Int Bool | + | data Header = Header Char Int Bool |

− | readHeader :: Get Header | + | readHeader :: Get Header |

− | readHeader = liftA3 Header get get get | + | readHeader = liftA3 Header get get get |

</haskell> | </haskell> | ||

or | or | ||

<haskell> | <haskell> | ||

− | readHeader = Header <$> get <*> get <*> get | + | readHeader = Header <$> get <*> get <*> get |

</haskell> | </haskell> | ||

− | Not using monads | + | <br>Not using monads, along with the <hask>do</hask> notation, can have advantages. |

− | Consider a generator of unique identifiers. | + | Consider a generator of unique identifiers. First you might think of a <hask>State</hask> monad which increments a counter each time an identifier is requested. |

− | First you might think of a <hask>State</hask> monad which increments a counter each time an identifier is requested. | + | |

<haskell> | <haskell> | ||

run :: State Int a -> a | run :: State Int a -> a | ||

Line 106: | Line 100: | ||

return (f x y) | return (f x y) | ||

</haskell> | </haskell> | ||

− | |||

If you are confident, that you will not need the counter state at the end and | 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 | 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), | (where the second block needs the state at the end of the first block), | ||

− | you can enforce a more strict scheme of usage. | + | you can enforce a more strict scheme of usage. The following is like a <hask>Reader</hask> monad, where we call <hask>local</hask> on an incremented counter for each generated identifier. Alternatively you can view it as [[Continuation]] monad. |

− | The following is like a <hask>Reader</hask> monad, | + | |

− | where we call <hask>local</hask> on an incremented counter for each generated identifier. | + | |

− | Alternatively you can view it as [[Continuation]] monad. | + | |

<haskell> | <haskell> | ||

Line 135: | Line 125: | ||

This way users cannot accidentally place a <hask>return</hask> | This way users cannot accidentally place a <hask>return</hask> | ||

somewhere in a <hask>do</hask> block where it has no effect. | somewhere in a <hask>do</hask> block where it has no effect. | ||

− | |||

=== Safety === | === Safety === | ||

Line 144: | Line 133: | ||

In an imperative language it is common to return an error code and provide the real work by side effects. | 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. | In Haskell this cannot happen, because functions have no side effects. | ||

− | If you ignore the result of a Haskell function the function will | + | If you ignore the result of a Haskell function, the function will not even be evaluated. |

The situation is different for <hask>IO</hask>: | The situation is different for <hask>IO</hask>: | ||

− | While processing the <hask>IO</hask> you might still ignore the contained return value. | + | While processing the <hask>IO</hask>, you might still ignore the contained return value. |

You can write | You can write | ||

Line 161: | Line 150: | ||

Is this behaviour wanted? | Is this behaviour wanted? | ||

− | + | There are possibilities to explicitly ignore return values in safety oriented languages | |

(e.g. <code>EVAL</code> in [http://www.modula3.org/ Modula-3]). | (e.g. <code>EVAL</code> in [http://www.modula3.org/ Modula-3]). | ||

Haskell does not need this, because you can already write | Haskell does not need this, because you can already write | ||

Line 208: | Line 197: | ||

=== Alternative combinators === | === Alternative combinators === | ||

− | If you are used to | + | If you are used to writing monadic functions using infix combinators <hask>(>>)</hask> and <hask>(>>=)</hask> |

you can easily switch to a different set of 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 <hask>Monad</hask> type constructor class, | + | This is useful when there is a monadic structure that does not fit into the current <hask>Monad</hask> type constructor class, where the monadic result type cannot be constrained. |

− | where the monadic result type cannot be constrained. | + | This is e.g. useful for the [http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros Set data type], where the element type must have a total order. |

− | This is e.g. useful for the [http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros Set data type], | + | |

− | where the element type must have a total order. | + | |

== Useful applications == | == Useful applications == | ||

− | It shall be mentioned that the <hask>do</hask> sometimes takes the burden from you | + | It shall be mentioned that the <hask>do</hask> sometimes takes the burden away from you of writing boring things. |

E.g. in | E.g. in | ||

<haskell> | <haskell> | ||

Line 225: | Line 212: | ||

return x | return x | ||

</haskell> | </haskell> | ||

− | a <hask>case</hask> on <hask>y</hask> is included, | + | a <hask>case</hask> on <hask>y</hask> is included, which calls <hask>fail</hask> if <hask>y</hask> is not a <hask>Right</hask> (i.e. <hask>Left</hask>), and thus returns <hask>Nothing</hask> in this case. |

− | which calls <hask>fail</hask> if <hask>y</hask> is not a <hask>Right</hask> (i.e. <hask>Left</hask>), | + | |

− | and thus returns <hask>Nothing</hask> in this case. | + | |

Also the <hask>mdo</hask> notation proves useful, since it maintains a set of variables for you in a safe manner. | Also the <hask>mdo</hask> notation proves useful, since it maintains a set of variables for you in a safe manner. | ||

Line 246: | Line 231: | ||

return ((x,y,z),x+y+z)) | return ((x,y,z),x+y+z)) | ||

</haskell> | </haskell> | ||

− | |||

== See also == | == See also == |

## Latest revision as of 16:57, 2 March 2016

## Contents |

## [edit] 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.

### [edit] 1.1 Didactics

TheThis 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"

instead of

putStrLn "text"

or

do text <- getLine return text

instead of

`getLine`

or

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 <- Just (5*7) return (x-y)

Or consider

do x <- Just (3+5) y <- Nothing return (x-y)

### [edit] 1.2 Library design

Unfortunately, theYou just write

data Header = Header Char Int Bool readHeader :: Get Header readHeader = liftA3 Header get get get

or

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 anewtype 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

### [edit] 1.3 Safety

*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 forYou 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
(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

New developments:

- 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

## [edit] 2 Happy with less sugar

### [edit] 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 ofHowever 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.

### [edit] 2.2 Alternative combinators

If you are used to writing monadic functions using infix combinatorsyou can easily switch to a different set of combinators.

This is useful when there is a monadic structure that does not fit into the currentThis is e.g. useful for the Set data type, where the element type must have a total order.

## [edit] 3 Useful applications

It shall be mentioned that theE.g. in

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

Compare

mdo x <- f x y z y <- g x y z z <- h x y z return (x+y+z)

and

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))

## [edit] 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