Personal tools

Do notation considered harmful

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(didactic problems)
(monadic return values)
Line 43: Line 43:
=== Library design ===
=== Library design ===
 +
 +
=== Safety ===
 +
 +
With <hask>do</hask> 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 <hask>IO</hask>:
 +
While processing the <hask>IO</hask> you might still ignore the contained return value.
 +
 +
You can write
 +
<haskell>
 +
do getLine
 +
putStrLn "text"
 +
</haskell>
 +
and thus silently ignore the result of <hask>getLine</hask>.
 +
The same applies to
 +
<haskell>
 +
do System.cmd.system "echo foo >bar"
 +
</haskell>
 +
where you ignore the <hask>ExitCode</hask>.
 +
Is this behaviour wanted?
 +
 +
In safety oriented languages there are possibilities to explicitly ignore return values
 +
(e.g. <code>EVAL</code> in [http://www.m3.org/ Modula-3]).
 +
Haskell does not need this, because you can already write
 +
<haskell>
 +
do _ <- System.cmd.system "echo foo >bar"
 +
return ()
 +
</haskell>
 +
Writing <hask> _ <- </hask> 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 <hask>do</hask> notation.
 +
It would suffice to restrict the type of the <hask>(>>)</hask> combinator to
 +
<haskell>
 +
(>>) :: m () -> m a -> m a
 +
</haskell>
 +
This way, you can omit <hask> _ <- </hask> only if the monadic return value has type <hask>()</hask>.

Revision as of 07:20, 5 November 2007

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

The
do
notation hides functional details.

This is wanted in order to simplify writing imperative style code fragments. The downsides are

  • that, since
    do
    notation is used almost everywhere, where
    IO
    takes place, newcomers quickly believe that the
    do
    notation is necessary for doing
    IO
    ,
  • and that newcomers think, that
    IO
    is 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"

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"

.

1.2 Library design

1.3 Safety

With
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
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 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 ()
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
()
.


2 See also

Retrieved from "http://www.haskell.org/haskellwiki/Do_notation_considered_harmful"

Category: Syntax