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.
Strongly +1.-- Conal
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.On Fri, Nov 7, 2014 at 10:00 AM, Edward Kmett <ekmett@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries