[EMAIL PROTECTED] wrote:
Takusen permits on-demand processing on three different levels. It is
specifically designed for database processing in bounded memory with
predictable resource utilization and no resource leaks.
But first, about getContents. It has been mentioned a while ago that
getContents should be renamed to unsafeGetContents. I strongly support
that suggestion. I believe getContents should be used sparingly (I
personally never used it), and I believe it cannot give precise
resource guarantees and is a wrong model for database interfaces.
I will not dwell on the fact that getContents permits IO to occur
while evaluating pure code -- which is just wrong. There is a
practical consequence of this supposedly theoretical impurity: error
handling. As the manual states ``A semi-closed handle becomes closed:
.... if an I/O error occurs when reading an item from the handle; or
once the entire contents of the handle has been read.'' That is, it is
not possible to tell if all the data from the channel have been read
or an I/O error has interfered. It is not possible to find out any details
about that I/O error. That alone disqualifies getContents from any
serious use. Even more egregious is resource handling and that
business with semi-closed handles, which is a resource
leak.
All of which constitutes the "lazy I/O considered harmful" folklore, which
really should be written up somewhere. Anyway, I just wanted to point out that
nowadays we have the option of using imprecise exceptions to report errors in
lazy I/O. The standard I/O library doesn't do this at the moment (I think it
would be good to have a discussion about whether it should sometime), but
Data.ByteString's lazy I/O does report errors using exceptions.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
