Bug in Control.Monad.State

[Josef Svenningsson]

Yitzchak,

I think you raise some very relevant questions about the design of Haskell
libraries and how to deal with strictness/laziness. In my experience very
few Haskell programmers have a feel for the strictness/laziness of a
program. Even seasoned Haskell programmers have a hard time with this.
Therefore I think that often the strictness/laziness of a function can be
accidental rather than well thought through, even in libraries. However,
this makes it even more important to think these issues through when
designing a Haskell library. It's an issue which hasn't got by far the
attention that it should have recieved.

About your request regarding the state monad. I think it is the wrong thing
to make >>= strict. 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. The gist of the problem is
that when you make >>= lazy it does not perform a tail call anymore. This
means that everytime you run >>= some piece of memory will be allocated. 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. But I very much agree with you that the library should provide a
lazy state monad for those moments when the programmer knows what he is
doing and he really wants laziness.

Incidentally I started working on a new monad library some time ago. The
library was designed with the explicit goal of giving the programmer options
about the strictness of functions and data structures while at the same time
being convenient to use. I think I managaged pretty well to accomodate those
goals. However, I never got around to finish it. Some day perhaps....

All the best,

/Josef

On 11/22/05, Yitzchak Gale <gale at sefer.org> wrote:
>
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/libraries/attachments/20051122/b6b18415/attachment.htm