mapM_ for bytestring

[Artyom Kazak]

On Fri, 06 Sep 2013 03:07:23 +0400, Johan Tibell <johan.tibell at gmail.com>  
wrote:

> I think the important issue here is whether we want to add monadic
> versions of functions in bytestring (where it makes sense)? It wield
> yield better performance than using `unpack`, but at the cost of lots
> of code duplication.
>
> We have the same issue in containers where you could for example want
> an `updateM` function, that would let you decide whether to update a
> value by performing some side effect. You could simulate this using a
> combination of `lookup` and `insert`, but that requires twice the
> number of traversals of the data structure.
>
> Right now I'm of the mind that the extra traversals (and using unpack
> in the case of ByteString) is better than the code duplication.

This code already is in bytestring — as part of `sort`. So, no code would
actually be duplicated, just moved. (And we get sortBy practically for  
free!)

Then, bytestring *is* code duplication. Raw loops everywhere, same raw  
loops
with minor changes; peekByteOff-pokeByteOff; calling C for 30% speed  
improvements
(and leaving loop-y Haskell versions commented nearby); and much more. I  
find
myself wondering if by carefully choosing a set of basic primitives the  
code
of bytestring could be made ten times shorter.