Simon Marlow wrote:

...

Simon Marlow:

...

[Lazy I/O] is nice, but it introduces too many problems. What happens to any I/O errors encountered by the lazy I/O? They have to be discarded, which means you can't effectively use lazy I/O for robust applications anyway.

Surely they are thrown as exceptions which can then be manipulated in pure code using

mapExceptions :: (Exception -> Exception) -> (a -> a)

and caught in the IO monad using catch?

No, the report clearly states that they are discarded.

Could you please point out where? I couldn't find it with a quick look.

We could perhaps have our own versions of the lazy I/O operations which throw exceptions, but this in itself is problematic because these kind of exceptions would be asynchronous in nature. If lazy I/O is allowed to raise exceptions, then we have a situation where evaluating anything can raise an I/O exception. In theory this shouldn't be a problem - we all ought to be writing asynchronous-excpetion-safe code anyway to protect against StackOverflow, but an I/O exception is often one that you want to handle gracefully and recover from. I feel distinctly uncomfortable about I/O exceptions being thrown by pure code, and even more uncomfortable about asynchronous I/O exceptions.

Is even the following example from the library report (section 11.8.2) problematic? import System import Char( toUpper ) main = do [f1,f2] <- getArgs s <- readFile f1 writeFile f2 (map toUpper s) -- Dean