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

[David Feuer]

That's ... surprising. I'm quite curious what exactly you tried. Did you
compile with optimizations? I see that in the Hackage version, foldMapA is
defined in a where clause of a recursive function. I wouldn't be surprised
if that could cause some trouble, especially if optimizations are disabled.
Side note: I doubt you're actually winning anything significant by having a
special case for [].

On Thu, May 9, 2019, 2:56 PM Vanessa McHale <vanessa.mchale at iohk.io> wrote:

> Interestingly, in the case of dir-traverse,
>
> foldMapA = (fmap fold .) . traverse
>
> ends up being faster than
>
> foldMapA f = getAp . foldMap (Ap . f)
>
> ...which I did not expect. I suppose we should benchmark this before
> adding it to base.
>
> Cheers,
> Vanessa McHale
> On 5/9/19 12:49 PM, chessai . wrote:
>
> 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
>>
>
> _______________________________________________
> 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/92803be8/attachment.html>