mapM_ for bytestring
yom at artyom.me
Fri Sep 6 15:57:48 CEST 2013
On Fri, 06 Sep 2013 03:07:23 +0400, Johan Tibell <johan.tibell at gmail.com>
> 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