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

[Dmitriy Kovanikov]

Vanessa, I'm not proposing to replace base with relude in libraries like
dir-traverse. Sorry if I wasn't clear enough, I didn't mean to introduce
more confusion.

I don't use `relude` in my libraries as well because I prefer a low amount
of external dependencies and I usually use alternative prelude only in big
applications.

As David mentioned, I indeed just wanted to show one more place where
`foldMapA` is introduced because it's not in base. Having `foldMapA` in
base will make `relude` even better because it will have even fewer custom
things in favour of mere reexports from base. I also think that if some
data type / function has already been in some alternative prelude for some
time, it could be a good addition to base.

On Thu, May 9, 2019 at 10:28 PM 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/8aaafc23/attachment.html>