Proposal: Add concatMapM function (#2042)

Simon Marlow simonmarhaskell at
Fri Feb 1 05:31:37 EST 2008

Bayley, Alistair wrote:
>> From: libraries-bounces at 
>> [mailto:libraries-bounces at] On Behalf Of Ketil Malde
>> Somebody raised the question of reading a Content-type field, etc:
>> would it be possible to "rewind" a handle after setting encoding?  For
>> Content-type fields, I suspect the header is usually limited to ASCII
>> anyway, so adding decoding for subsequent text is probably
>> sufficient.
> I think this is relevant:

We've talked a lot in the past about a stream-layering IO abstraction. 
I'd forgotten about Oleg's post, thanks.

Here are some others.  There's the prototype I worked on:

There's Bulat's Stream library, which is pretty complete:

And Takano Akio's version, in which he divides the type classes into 
smaller pieces.  This is closer to the direction I thought we should go:

Right now though, I'm not sure all this is going in the right direction. 
Dealing with all those mutable buffers is quite a headache (for the library 
writer, not the user), and lazy bytestrings have shown us that there are 
simpler ways to get good I/O performance.  What's more, as Duncan Coutts 
has pointed out to me on more than one occasion, it's much easier to layer 
streams when the streams are lazy lists.  As much as I hate to say it, 
there's a lot to be said for lazy I/O in this respect.  However, lazy I/O 
has other problems - deterministically catching errors, unpredictable 
resource usage, unpredictable interaction with other I/O, and so on.  Is 
there a nice solution?  Something else we might look at is Oleg's left folds:


More information about the Libraries mailing list