Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

[David Feuer]

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" <conal at conal.net> 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 <ekmett at gmail.com> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141108/d660ac32/attachment.html>