Bug in Control.Monad.State

[Iavor Diatchki]

Hello,
It is not clear to me what is the right thing to do here (although I
agree that the transformer and the monad should be consistent).  In
'monadLib' at first I was very careful to make things as lazy as
possible, but then I noticed that this was a source of memory leaks,
that a user of the library could not really avoid.  So now I have
started making things stricter, not  in the state itself, but rather
the pair (result,state).  One always has to watch out for mfix, of
course, but things appear to be working at the moment.
-Iavor

On 11/21/05, Yitzchak Gale <gale at sefer.org> wrote:
> In the following thread, I reported a problem I
> was having with programs diverging when they use
> infinite lists with StateT:
>
> http://www.haskell.org//pipermail/haskell-cafe/2005-November/012253.html
>
> Roberto Zunino and Wolfgang Jeltsch pointed out
> that this is a bug in Control.Monad.State: (>>=)
> is lazy in State, but strict in StateT.
>
> The source of the problem is that the pattern
> match in the definition of (>>=) is inside a let
> expression in State - so it is lazy - but inside a
> do expression inside StateT - so it strict.
>
> Roberto suggests a one-byte patch to fix this
> problem: add '~' to make the pattern match in
> StateT irrefutable.
>
> (Note that this has already been done for the
> MonadFix instance of StateT.)
>
> The same fix should be applied to evalStateT and
> execStateT. They are also stricter than their
> non-transformer counterparts, for the same reason.
>
> -Yitz
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>