+1 for the Farkas-Dyck patch. Someone should check the performance of the replacement filterM, though: those loops may have been there for a reason that is still valid. On Tue, Jul 7, 2015 at 9:51 AM Edward Kmett wrote:

+1 from me.

-Edward

On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita wrote:

...

I noticed that traceM is generalized to use Applicative. Then, how about replicateM/replicateM_?

I don't quite like confusing names, but is better than needlessly restrictive.

_______________________________________________ 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

We made a blanket call on a half-dozen earlier similar proposals a while back to simply consider the M to be a more generalized suffix, as a majority of the fooM combinators can be generalized in this way. The alternative duplicates almost all of the APIs and provides no good migration plan. In addition, moving them requires a rather annoying period of code breakage, and fosters situations where users who want to have a wide support window just can't use the new functionality or never realize it is there. Generalizing them in place, however, grants optimization improvements to existing users. liftM vs. liftA continues to exist because they actually serve a purpose as a valid default definition for fmap in terms of return and (>>=) or pure and (<*>) respectively. liftMn vs. liftAn on the other hand, will continue to exist for historical reasons, but we shouldn't seek to emulate that pattern. We may actually eventually switch liftMn to just invoke liftAn if we can show it doesn't introduce any problems, but as this hasn't yet been shown, we're doing nothing there at the moment. -Edward On Tue, Jul 7, 2015 at 1:25 PM, Ömer Sinan Ağacan wrote:

(looking at the patch) Shouldn't we rename them to `filterA`, `replicateA` etc. and move to Control.Applicative module? (like `liftM` vs. `liftA`)

2015-07-07 12:58 GMT-04:00 Bart Massey :

...

+1 for the Farkas-Dyck patch. Someone should check the performance of the replacement filterM, though: those loops may have been there for a reason that is still valid.

On Tue, Jul 7, 2015 at 9:51 AM Edward Kmett wrote:

...

+1 from me.

-Edward

On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita wrote:

...

I noticed that traceM is generalized to use Applicative. Then, how

about

...

...

replicateM/replicateM_?

I don't quite like confusing names, but is better than needlessly restrictive.

_______________________________________________ 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