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? In an monadic IO style you have a loop that reads stuff from a Handle and then processes it in chunks. Each time you read from the Handle it could raise an IO exception. So you get to either locally deal with the exception or let the exception propagate (ie jumping out of your loop). The latter is probably more common since in your inner loop you probably don't know how to handle it, eg do you retry or do something else. So if we're usually handling the error outside the IO loop then what is different with doing that by using lazy IO and then catching the error (thrown from pure code and caught in IO code) ? We could probably even arrange to keep the partially processed input up to the current point so that we could retry or deal with partial input rather than having to restart from the beginning of the stream (which may not be possible say for a pipe or socket). Besides, it's not even true that error handling at that level is easy. As soon as you start building abstractions you blur the notion of where you are in the stream, and so precise error locations disappear. The only way to retain that is to invert your control flow so that you push data into your algorithm rather than your algorithm pulling data from a stream. It's not very pleasant writing code that way. </rant> Duncan