Proposal: add foldMapA to Data.Foldable or Control.Applicative
Vanessa McHale
vanessa.mchale at iohk.io
Thu May 9 18:56:38 UTC 2019
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
> <mailto: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
> <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 <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/d06bc54e/attachment-0001.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/d06bc54e/attachment-0001.sig>
More information about the Libraries
mailing list