Robert Dockins wrote:
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...
Haskell prevents you from opening a file for writing while you already have it open for reading (even if the reading is being done lazily). This is an oft-forgotten part of the Haskell I/O library specification, perhaps because only GHC implements it (and even GHC doesn't implement it on all platforms). But in principle I agree, we would like to think of hGetContents as pulling lazilly from an immutable array of bytes, and if that were the case then there would be no problem. Cheers, Simon