oleg@pobox.com 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