Proposal: add foldMapA to Data.Foldable or Control.Applicative

Vanessa McHale vanessa.mchale at
Thu May 9 18:56:38 UTC 2019

Interestingly, in the case of dir-traverse,

foldMapA = (fmap fold .) . traverse

ends up being faster than

foldMapA f = getAp . foldMap (Ap . f)

...which I did not expect. I suppose we should benchmark this before
adding it to base.

Vanessa McHale

On 5/9/19 12:49 PM, chessai . wrote:
> I've also defined this in multiple of my own projects/codebases, and I
> provided it as a motivation for introducing Data.Monoid.Ap in the
> first place.
> I'm +1 on the inclusion of foldMapA.
> On Thu, May 9, 2019, 11:10 AM Matt <parsonsmatt at
> <mailto:parsonsmatt at>> wrote:
>     I've personally defined `foldMapA` in at least three private
>     projects, and I've one-off written it probably over a dozen times.
>     Each time I've used something like `fmap k . traverse f` where `k`
>     is one of `mconcat`, `fold`, `join`, etc. I appreciate the subtle
>     discussion on the implementation for performance and I think it'd
>     be awesome to have this defined in `base`.
>     Matt Parsons
>     On Tue, May 7, 2019 at 10:36 PM David Feuer <david.feuer at
>     <mailto:david.feuer at>> wrote:
>         On Wed, May 8, 2019, 12:12 AM Bryan Richter <b at
>         <mailto:b at>> wrote:
>             Hi David,
>             At the risk of invoking the gods of Language Blorp, I will
>             note that as a working programmer I know exactly what
>             Applicative, Traversable, and Monoid are (from Vanessa's
>             original proposal), but the unfortunately-named getAp is
>             something I will only learn about begrudgingly.
>         That seems unfortunate. Learning to use such types is pretty
>         useful. I'd recommend that every Haskell programmer get to
>         know all the types in Data.Monoid and come to an understanding
>         of what they're good for.
>             What you consider "so simple we don't need to define it"
>             took a rather lengthy email to describe. Are you sure it's
>             not worth actually defining?
>         So ... that long post was about trying to prove what I
>         intuitively thought *must* be true. In the end, I wasn't quite
>         able to finish the proof, but I did at least manage to
>         convince myself that my intuition was correct. It's true that
>         this sort of intuition takes a certain amount of time to
>         develop. In the case of a really important operation, yeah, we
>         should package it up. But is this operation important enough?
>         I'm not really convinced yet.
>             If nothing else, the next time someone searches Hoogle for
>             a function matching its type signature, perhaps it will be
>             an opportunity for someone like me to peer beneath the
>             hood and learn something new.
>         That's valid. But ... there are lots of opportunities for that
>         sort of thing already. Is it worth the API clutter to add
>         another one?
>         _______________________________________________
>         Libraries mailing list
>         Libraries at <mailto:Libraries at>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at <mailto:Libraries at>
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Libraries mailing list