Proposal: Add concatMapM function (#2042)

[Simon Marlow]

Bayley, Alistair wrote:
>> From: libraries-bounces at haskell.org 
>> [mailto:libraries-bounces at haskell.org] 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:
>  
> http://www.haskell.org/pipermail/haskell-cafe/2004-September/006801.html

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:

http://www.haskell.org/~simonmar/io/System.IO.html

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

http://haskell.org/haskellwiki/Library/Streams

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:

http://yogimo.sakura.ne.jp/ssc/

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:

http://okmij.org/ftp/Haskell/#fold-stream
http://www.haskell.org/pipermail/haskell/2003-September/012741.html

Cheers,
	Simon