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

[Carter Schonwald]

derp, the Ap newtype for getting a monoid from aplicative f over monoid

On Thu, May 9, 2019 at 10:38 AM David Feuer <david.feuer at gmail.com> wrote:

> Carter, I already showed that it is, and Dmitriy already refined that
> definition.
>
> On Thu, May 9, 2019, 10:35 AM Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> Its a complicated landscape, and we're still learning.
>>
>> if a new combinator is hard to write:
>> a) how do we help educate folks into seeing it as an easy combinator
>> b) what are the with/without fusion cost models of different
>> implementations?
>> c)  is it useful?
>>
>> I’m slightly inclined to support inclusion.
>>
>> One question I have is whether it’s definable via foldmap itself ?
>>
>> On Wed, May 8, 2019 at 12:36 AM 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/20190511/55b65b90/attachment.html>