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

[David Feuer]

Vanessa, it's very common for discussions about adding things to base (or
containers, etc) to get into how those matters have been handled elsewhere.
Many people think that it's better to pull ideas into base only after
they've demonstrated their value elsewhere. Dmitriy's comment should
definitely not be taken as criticism of your proposal.

Dmitriy, there's no question that (#.) or similar should be used rather
than (.). I didn't mention that because it doesn't seem to bear on the
overall question of whether the function should be added, and I didn't want
to confuse other participants with semi-obscure coercion operators.

On Thu, May 9, 2019, 10:28 AM Vanessa McHale <vanessa.mchale at iohk.io> wrote:

> 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> 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 listLibraries at haskell.orghttp://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/c0b2bd7c/attachment.html>