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

[Vanessa McHale]

I appreciate the more efficient version, but I do not consider a package
like relude to be an alternative to base (due to dependencies, maintenance).

On 5/8/19 10:50 PM, Dmitriy Kovanikov wrote:
> 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
> <mailto:david.feuer at gmail.com>> wrote:
>
>     On Wed, May 8, 2019, 12:12 AM Bryan Richter <b at chreekat.net
>     <mailto: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 <mailto: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/927be6d2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190509/927be6d2/attachment.sig>