mapM_ for bytestring

Edward Kmett ekmett at
Wed Sep 11 16:28:21 CEST 2013

We can't just upgrade those classes to be type family based, as this
destroys their support for polymorphic recursion.

We could write another class though.

The question is if that class belongs in base or in some other package, as
it takes is pretty far afield of anything purporting to be portable.

On Wed, Sep 11, 2013 at 9:35 AM, Duncan Coutts <duncan.coutts at
> wrote:

> On Thu, 2013-09-05 at 18:51 -0400, Edward Kmett wrote:
> > The maintainers for bytestring are still listed as Don Stewart and Duncan
> > Coutts on the package, and it doesn't seem to fall the list of core
> > packages per so I
> > suppose it would come down to talking one of them into taking the patch.
> Yes, I'm happy to consider pull requests.
> I should say that I start off sceptical about any additions to this API.
> As Raymond Chen says, each new feature starts off with -100 points.
> 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.
> Duncan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list