= 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
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
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
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries