[Haskell] Re: installing streams library

[Simon Marlow]

Duncan Coutts wrote:

> Personally I rather like the idea of a new IO library based on lazy byte
> strings or in this context it'd be more helpful to call them lazy byte
> streams. I believe this could give us a system which is much more
> idiomatic Haskell than an explicit buffer/IO based system and with
> almost as good performance (by almost I mean at most 10%, not 50%).
> 
> The idea is that instead of pushing things like string encoding or
> compression into the IO part of the system that we can leave it in the
> pure part and get nicer code and still get good performance. That is,
> instead of layering encoding etc into a stream that we can write things
> like:
> 
> print . count . lines . decode utf8 . gunzip  =<< readFile "foo"
> 
> and have that run within 10% of the speed of C code.

What about error handling?  At the moment, the lazy string returned by 
readFile is just truncated when an error occurs, and the error itself is 
discarded.  I don't think anyone wants this behaviour.

Now you could make purely functional code raise I/O exceptions, but that 
gives rise to a few problems: imprecise exceptions are difficult to 
program with (need deepSeq etc.), and they aren't widely implemented 
(Hugs doesn't have them, JHC doesn't have them and may not get them 
IIUC).  Also, laziness gives rise to problems with predictable resource 
consumption - many times we've had to explain to people how to make sure 
that the file opened by readFile is closed early enough so they don't 
run out of file descriptors or run into a locking problem.

Maybe lazy I/O can be made to work, but until/unless we have a good way 
to handle errors I'm certain it's not something on which we should be 
basing a new I/O library design.

Cheers,
	Simon