Yitzchak,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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....<br>
<br>
All the best,<br>
<br>
/Josef<br>
<br><div><span class="gmail_quote">On 11/22/05, <b class="gmail_sendername">Yitzchak Gale</b> <<a href="mailto:gale@sefer.org">gale@sefer.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Iavor,<br><br>> It is not clear to me what is the right thing to do here (although I<br>> agree that the transformer and the monad should be consistent). In<br>> 'monadLib' at first I was very careful to make things as lazy as
<br>> possible, but then I noticed that this was a source of memory leaks,<br>> that a user of the library could not really avoid. So now I have<br>> started making things stricter,<br><br>Lack of laziness is also a serious problem that a
<br>user cannot avoid. In my case, I have to<br>completely rewrite StateT, otherwise it is totally<br>unusable. This is definitely a bug.<br><br>If you make State strict, I am sure it would break<br>many existing programs. (It would certainly break
<br>many of mine.) I doubt that very much existing<br>code is relying on the accidental strictness in<br>StateT.<br><br>Strictness is a problem throughout the Haskell<br>libraries. There was a recent discussion about<br>
Data.Map, for example. Right now, there seems to<br>be a need for at least two different versions of<br>every single container and monad in the library,<br>depending on strictness. It would be great if<br>someone could come up with a nicer and more
<br>general approach.<br><br>(And if not - it would be nice of all of those<br>different versions would be added already.)<br><br>If we are forced to choose one or the other, I<br>would definitely vote for the lazy<br>version. Otherwise, what have we accomplished by
<br>using Haskell?<br><br>Regards,<br>Yitz<br>_______________________________________________<br>Libraries mailing list<br><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/libraries">
http://www.haskell.org/mailman/listinfo/libraries</a><br></blockquote></div><br>