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

[Dmitriy Kovanikov]

I would like to add one more point of reference to the discussion. The
`foldMapA` function is also implemented in the `relude` alternative prelude:

http://hackage.haskell.org/package/relude-0.5.0/docs/src/Relude.Foldable.Fold.html#foldMapA

And the implementation already uses `Ap` and `getAp` as was discussed here.
Previous implementation used `fmap` and `traverse` but it was changed to a
more efficient one.

One possible improvement: instead of current implementation

> foldMapA f = getAp . foldMap (Ap . f)

It can be slightly more efficient (I guess) by using #. operator to coerce
newtypes

> foldMapA f = getAp #. foldMap (Ap . f)

The implementation in `relude` also contains recommended order of variables
under `forall`. After using `foldMapA` in production for a while we've
figured out in what order variables should go to resolve most often
ambiguities via TypeApplication.

On Wed, May 8, 2019 at 12: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190509/ec8ecfd0/attachment.html>