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@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:


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@gmail.com> wrote:
On Wed, May 8, 2019, 12:12 AM Bryan Richter <b@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries