Bug in Control.Monad.State

[Yitzchak Gale]

Hi Iavor,

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

Lack of laziness is also a serious problem that a
user cannot avoid. In my case, I have to
completely rewrite StateT, otherwise it is totally
unusable.  This is definitely a bug.

If you make State strict, I am sure it would break
many existing programs. (It would certainly break
many of mine.) I doubt that very much existing
code is relying on the accidental strictness in
StateT.

Strictness is a problem throughout the Haskell
libraries.  There was a recent discussion about
Data.Map, for example.  Right now, there seems to
be a need for at least two different versions of
every single container and monad in the library,
depending on strictness. It would be great if
someone could come up with a nicer and more
general approach.

(And if not - it would be nice of all of those
different versions would be added already.)

If we are forced to choose one or the other, I
would definitely vote for the lazy
version. Otherwise, what have we accomplished by
using Haskell?

Regards,
Yitz