On Wed, Oct 21, 2009 at 9:44 AM, Michael Mossey
Magnus Therning wrote:
On 20/10/09 20:32, Michael Mossey wrote:
Okay, I figured this out. mapM is not lazy, at least not for a monad that has state and under the circumstance you demand the state out the other side.
If I understand what you are saying then this behaviour isn't unexpected. If you have a monad with state, and you ask for the final state, then it's likely that everything happening in that particular monad will has to be evaluated.
Hi Magnus,
Yes, that's what I was trying to imply. I realized it is mathematically impossible for mapM to be lazy for a monad with state.
mapM doesn't seem to be lazy anywhere. For example, this program
main = do buffers <- forM ["file1.txt","file2.txt","file3.txt"] readFile print . take 1 . concat $ buffers
will, according to my experiments with the profiler, read all three files. It's possible to imagine lazy behavior here, but no doubt there is a technical reason against it.
Laziness in combination with IO is a difficult thing. Just search the archives to see the number of threads about it.
I may rewrite the program. Or I may consider the ISS principle. ("Increase the stack, stupid.")
You may also be able to improve the situation by adding a bit of strictness. In some cases the thunks resulting from laziness can take up a lot of space. Forcing evaluation, at well thought out locations in your program, may both speed things up and reduce memory/stack usage.
You are probably right... I am having trouble spanning the gap between "my current understanding" and "well thought-out locations." Real World Haskell has a chapter on this, so I may look there.
I was able to get the program to run by removing all places that I had created a chain of Rand computations that forced evaluation of the last one. I replaced these with computations that did not require evaluation of the last one.
However, my program was still forced to read more files than it really needed in the end, as the above snippet demonstrates.
Just out of curiosity, did you verify that all three files were completely *read*, as opposed to all three opened, but only the first line of the first file being read? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe