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

[chessai .]

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 gmail.com> 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 gmail.com> wrote:
>
>> On Wed, May 8, 2019, 12:12 AM Bryan Richter <b at chreekat.net> 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 haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190509/8f5cc824/attachment.html>