Generalizing replicateM?

Edward Kmett ekmett at gmail.com
Tue Jul 7 18:40:42 UTC 2015


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 <omeragacan at gmail.com>
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 <bart.massey at gmail.com>:
> > +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 <ekmett at gmail.com> wrote:
> >>
> >> +1 from me.
> >>
> >> -Edward
> >>
> >> On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita <fumiexcel at gmail.com>
> >> 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 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
> >
> >
> > _______________________________________________
> > 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/20150707/e04cde78/attachment.html>


More information about the Libraries mailing list