[Haskell-cafe] IO is not a monad

Yitzchak Gale gale at sefer.org
Wed Feb 7 06:59:15 EST 2007

Aaron McDaid wrote:
> Apologies for referring to this old thread...

At least for me, this is not old. It is still very
much on my mind.

> Simply, 'undefined >> undefined' is a bit more defined than simply
> 'undefined'. Just like 'undefined:undefined' is at least a non-empty
> list; which can be matched by (_:_) for example. This explains the
> differing behaviour of the two seemingly equivalent actions above.

I think you are correct. And that is the problem.

As a simple Haskell programmer, I am starting from
the fact that seq exists and works in a certain

Given that reality, I want to look at what monads
should look like and what strictness properties they
should have.

Well, even with seq around, Haskell types and
functions still form a nice category - except you
have to be careful to use strict composition
instead of regular Haskell composition when
viewing Haskell functions as morphisms in
the category.

So then what is a monad? There is
one obvious extra requirement:

Monad Strictness Law:
(>>=) must be strict in its second argument.

That law follows from the monad law:

(>>= f) .! return = f

when we take f = _|_ (and we make the
assumption that our monad is not
degenerate - return x /= _|_ for some x).

Making (>>=) strict in the second argument
would be a very minor change. That
change would affect few, if any, existing
Haskell programs.

I am becoming convinced that this should be
considered a bug in IO.

Unfortunately, I don't think that fixing this
bug will help much with other known monad
strictness problems, such as the State/StateT
strictness bug.


More information about the Haskell-Cafe mailing list