[Haskell] Re: installing streams library
simonmarhaskell at gmail.com
Wed May 24 05:51:31 EDT 2006
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
> 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.
More information about the Haskell