[Haskell-cafe] Re: Takusen and strictness, and perils of getContents

[Simon Marlow]

oleg at 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