Excerpts from Henning Thielemann's message of Sun Mar 22 22:52:48 +0100 2009: > > On Sun, 22 Mar 2009, nicolas.pouillard wrote: > > > Excerpts from Henning Thielemann's message of Sat Mar 21 22:27:08 +0100 > > 2009: > >> > >> Maybe you know of my packages lazy-io and explicit-exception which also > >> aim at lazy I/O and asynchronous exception handling. > > > > I was indeed aware of these two packages but I think they hold orthogonal > > ideas. > > > > About the lazy-io package, as explained in the documentation one has to > > carefully choose which operations can be lifted. In safe-lazy-io I try > > to choose a set of well behaving combinators to replace 'getContents' in the > > IO monad. > > > > Moreover if I take the three problems of standard lazy IO in turn: > > 1/ Control of resources: One advantage over standard lazy IO is that > > the file opening can also be done lazily, avoiding an immediate > > resource exhaustion. However one still relies on evaluation and garbage > > collection to take care of closing handles, which is not satisfying since > > handles are scarce resources. > > 2/ Control of exceptions: If one writes a 'getContents' function such that > > it no longer hides I/O errors during reading, how do you guarantee > > that exceptions will happen during the LazyIO.run and not after? > > Currently I cannot guarantee anything. However my idea is to stay away > from built-in exceptions in IO. In explicit-exception there is an > experimental hidden module which provides an IO monad wrapper called SIO > which cannot throw any IO exception. > http://code.haskell.org/explicit-exception/src/System/IO/Straight.hs > Actually, I think it's the wrong way round to build an exception-free > monad on top of one with exceptions. Instead IO should be built on top of > SIO, but that's not possible for historical reasons. > The only safe operation to get into SIO is > ioToExceptionalSIO :: IO a -> ExceptionalT IOException SIO a > That is, it makes exceptions explicit and SIO operations can never throw > IO exceptions. You should convert synchronous explicit exceptions of > atomic operations like getChar into asynchronous explicit exceptions, > combine them lazily to big operations like getContents. Then you get > getContents :: SIO (Asynchronous.Exception IOException String) > If you run lazy SIO operations you can't become surprised by exceptions.
It sounds like a nice idea, it would be great to have a straight-io package to play a bit more with explicit exceptions in things like 'IO'. For safe-lazy-io I wanted to keep the exception management as light as possible. In particular when writing programs where most of the 'IO' errors are considered fatals---EOF is not fatal of course but using getContents one do not see it. > > 3/ Determinism: when freely combining multiple inputs one risks the problem > > mentioned by Oleg [1], when using your package it will depend on > > the 'getContents' function we use: > > a) if we 'liftIO' the standard 'getContents' function, we can have the > > issue. > > b) if we write a new 'getContents' as below [2], then (if I got right > > your lazy IO monad) all reads are chained. And then one has > > to process inputs in the same order. > > I wouldn't build hClose into getContents, because you never know, whether > the file is read until it's end. If you call a LazyIO.getContents twice, > the contents are read sequential. In order to read file contents > simultaneously you must call (LazyIO.run LazyIO.getContents) twice in the > IO monad. Right but one of the purposes of safe-lazy-io is to provides a good management of file handles in particular closing them. Actually the implementation of lazy inputs focus particularly on that---through the 'Finalized' values. http://hackage.haskell.org/packages/archive/safe-lazy-io/0.1/doc/html/src/System-IO-Lazy-Input-Internals.html -- Nicolas Pouillard _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe