mapM_ for bytestring

Edward Kmett ekmett at
Wed Sep 11 20:29:29 CEST 2013

mapM_ is actually implemented in terms of Foldable, not Traversable, and
its implementation in terms of folding a ByteString is actually rather slow
in my experience doing so inside lens and isn't much faster than the naive
version that was suggested at the start of this discussion.

But as we're not monomorphizing Foldable/Traversable, this isn't a think
that is able to happen anyways.


On Wed, Sep 11, 2013 at 2:25 PM, Henning Thielemann <
lemming at> wrote:

> On Wed, 11 Sep 2013, Duncan Coutts wrote:
>  For mapM etc, personally I think a better solution would be if
>> ByteString and Text and other specialised containers could be an
>> instance of Foldable/Traversable. Those classes define mapM etc but
>> currently they only work for containers that are polymorphic in their
>> elements, so all specialised containers are excluded. I'm sure there
>> must be a solution to that (I'd guess with type families) and that would
>> be much nicer than adding mapM etc to bytestring itself. We would then
>> just provide efficient instances for Foldable/Traversable.
> I'd prefer to keep bytestring simple with respect to the number of type
> extensions. Since you must implement ByteString.mapM anyway, you can plug
> this into an instance definition of Traversable ByteString.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list