On May 26, 2006, at 6:52 AM, Simon Marlow wrote:
Duncan Coutts wrote:
On Thu, 2006-05-25 at 16:41 -0700, Ashley Yakeley wrote:
Malcolm Wallace wrote:
Oh, I always assume lazy I/O. It is one of the most useful parts of Haskell, and I rely on it all the time for both interactivity and avoidance of space problems.
Lazy I/O is problematic and probably a bad idea for libraries: http://haskell.org/pipermail/haskell/2006-May/017998.html Assuming we do have imprecise exceptions what is wrong with lazy IO?
I'm not even certain that lazy I/O doesn't upset referential transparency. It seems hard to construct a concrete counter example though. My intuition is something like this: if evaluating a thunk can cause IO to take place, then the act of evaluating that thunk might affect the value of another lazy I/O computation, and hence it should be possible to get different results by evaluating the thunks in a different order. I'm concerned that in the presence of dependencies between lazy I/O computations, the order of evaluation might be visible.
I'm personally with you on this one. However, I think it is mostly just a problem with current state-of-the-art filesysems. We could solve this problem with a filesystem that models files as persistent data structures (on-disk ropes maybe?). Then "writing" to a file just creates a new version of the persistent datastructure and updates the "name table" to point to the newest version; in fact, updating the name would be optional! I can think of a couple of use cases for modifying on-disk files and keeping them private to my process. Doing "lazy I/O" on a file just means keeping a reference to a particular version of the datastructure instead of getting the latest one from the name table. Obviously, there's some issues with garbage collecting unreferenced file versions, but I don't think the issues are any more complicated than for a journaling FS (caveat: I'm not at all a filesystem guru; I could be wrong). Actually, the more I think about it, the more I like this idea... Anyway, what I'm saying is that I think a filesystem/OS that supports persistent files could solve the problems with lazy I/O. After all, the proof obligation incurred by using lazy I/O is essentially "this file will not change between now and the last reference I make to its contents".
There have been several discussions on this topic, not everyone shares my views :-) eg.
http://www.haskell.org//pipermail/haskell-cafe/2003-October/ 005188.html
Actually, in a way I really hope I'm wrong. I would love to use lazy I/O, but I believe we need to have a good story for error handling and possible evaluation-order issues first.
Cheers, Simon
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG