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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
