Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

I think it's sufficiently clear that enough people want liftA4 and liftA5 to justify adding them. The remaining question is whether to save on code size by defining liftM = liftA --not = fmap, because fmap may be defined as liftM/liftA liftM2 = liftA2 -- I made this possible already by defining ap directly, so this won't cause problems for the (<*>) = ap bunch liftM[345]=liftA[345] The code size impact is larger than it might otherwise appear because of some SPECIALISE pragmas. On Nov 8, 2014 11:28 AM, "Conal Elliott" wrote:

Strongly +1.

liftAn are partial-application-friendly. They're also very handy to compose with *no arguments* in the style of semantic editor combinators. For instance, `(liftA2.liftA2.liftA2)` lifts a binary function to a binary function that targets three levels deep in applicative functor nesting.

-- Conal

On Fri, Nov 7, 2014 at 10:00 AM, Edward Kmett wrote:

...

If you want to partially apply a lifted function the f <$> x <*>y <*> z approach doesn't work.

liftMn and liftAn still have a place.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries