<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Generalizing them in place, however, grants optimization improvements to existing users.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 7, 2015 at 1:25 PM, Ömer Sinan Ağacan <span dir="ltr"><<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(looking at the patch) Shouldn't we rename them to `filterA`,<br>
`replicateA` etc. and move to Control.Applicative module? (like<br>
`liftM` vs. `liftA`)<br>
<div class="HOEnZb"><div class="h5"><br>
2015-07-07 12:58 GMT-04:00 Bart Massey <<a href="mailto:bart.massey@gmail.com">bart.massey@gmail.com</a>>:<br>
> +1 for the Farkas-Dyck patch. Someone should check the performance of the<br>
> replacement filterM, though: those loops may have been there for a reason<br>
> that is still valid.<br>
><br>
> On Tue, Jul 7, 2015 at 9:51 AM Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
>><br>
>> +1 from me.<br>
>><br>
>> -Edward<br>
>><br>
>> On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita <<a href="mailto:fumiexcel@gmail.com">fumiexcel@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> I noticed that traceM is generalized to use Applicative. Then, how about<br>
>>> replicateM/replicateM_?<br>
>>><br>
>>> I don't quite like confusing names, but is better than needlessly<br>
>>> restrictive.<br>
>>><br>
>>> _______________________________________________<br>
>>> Libraries mailing list<br>
>>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
</div></div></blockquote></div><br></div>