mapM_ for bytestring

Artyom Kazak yom at
Fri Sep 6 15:57:48 CEST 2013

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

> 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  

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

More information about the Libraries mailing list