Bug in Control.Monad.State
gale at sefer.org
Tue Nov 22 18:34:44 EST 2005
> ...Experience tells us that most programmers
> program as if >>= were strict and the lazy
> version usually gives problems. That is why, for
> instance, the ST monad is strict by default.
That is only true for IO. And for ST, which is
really just IO restricted to IORefs. In these
unusual monads that interact with the Real World,
one expects strictness.
The monads of the mtl library - and most others -
are meant for pure programs that lend themselves
to monadic paradigms. Here one expects laziness,
as usual in Haskell.
Many monad beginners do seem to make the mistake
you are referring to. The reason is that they
start by using only the IO monad before learning
much else about what monads are for. I think that
will improve once we begin to see more
introductions to Haskell geared to practical
> As an example, consider a server of some sort
> with an inner loop using a state monad. Making
> >>= lazy will mean that the server will
> inevitably run out of memory.
Servers interact with the Real World, so you would
use IO and ST. But you are right, it would be
great to have special strict versions of various
monads (and containers like Data.Map) for these
More information about the Libraries