Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

[Andreas Abel]

I am a bit alert about this discussion because it seems that we have 
quite different ideas about how the AMP implementation should affect the 
base libraries.

1. Where can we see and discuss the proposed changes?

Not on 
https://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal

Not on https://ghc.haskell.org/trac/ghc/ticket/9586

2. Imho, the reasonable thing is to

   rewrite all of F/A/M base functions such that they use the minimal 
F/A/M constraints.

This of course includes

   liftM  :: (Functor m) => (a -> b) -> m a -> m b
   liftM2 :: (Applicative m) => (a -> b -> c) -> m a -> m b -> m c

and sequence and friends even if the M postfix can then "only explained 
historically" (HT).

One can say "M" stands for "effectful", but the minimal type class to 
realize the effect is chosen from F/A/M.

If we burn bridges, we should do it properly.

Cheers,
Andreas


On 07.11.2014 20:35, Edward Kmett wrote:
> I don't want them for rewriting liftM4 and liftM5, I want them in their
> own right.
>
> It doesn't do anyone any good to just have random asymmetries in the API
> like that.
>
> It just means a user goes to reach for a tool, doesn't find it and
> flails around.
>
> -Edward
>
> On Fri, Nov 7, 2014 at 1:37 PM, John Lato <jwlato at gmail.com
> <mailto:jwlato at gmail.com>> wrote:
>
>     I still don't think it's worth adding liftA4 and liftA5 just so that
>     liftM4+ can be rewritten.
>
>     Very weakly -0.1
>
>     On Fri Nov 07 2014 at 10:24:27 AM David Feuer <david.feuer at gmail.com
>     <mailto:david.feuer at gmail.com>> wrote:
>
>         Another point: using `liftA` or `liftM`, specialized to the
>         relevant type, may reduce code size in some cases. With f <$> a
>         <*> b <*> c and such, you have to hope that you either get some
>         benefit from the inlining or that CSE is able to save you from
>         the duplication.
>
>         On Fri, Nov 7, 2014 at 7:47 AM, Jacques Carette
>         <carette at mcmaster.ca <mailto:carette at mcmaster.ca>> wrote:
>
>             On 2014-11-07 5:30 AM, Henning Thielemann wrote:
>
>
>                 On Fri, 7 Nov 2014, Andreas Abel wrote:
>
>                     I hope the same happens for sequence, mapM and the like!
>
>                       sequence :: (Applicative m) => [m a] -> m [a]
>                       sequence = foldr (\ x xs -> (:) <$> x <*> xs)
>                     (pure [])
>
>
>                 Actually, this is an example, where liftA2 shows its
>                 advantage:
>
>                    sequence = foldr (liftA2 (:)) (pure [])
>
>                 This looks much clearer to me than decoding the mixture
>                 of infix and uninfixed infix operators. It simply says,
>                 that 'sequence' is like 'id = foldr (:) []' but with
>                 everything lifted to an applicative functor.
>
>
>             I agree.  I have lots of code which looks really clean
>             because I can use liftA2 (and even liftA3) in exactly the
>             way above.  Having to eta expand everything obscures the
>             real meat of what is going on.
>
>             Jacques
>
>             _________________________________________________
>             Libraries mailing list
>             Libraries at haskell.org <mailto:Libraries at haskell.org>
>             http://www.haskell.org/__mailman/listinfo/libraries
>             <http://www.haskell.org/mailman/listinfo/libraries>
>
>
>         _________________________________________________
>         Libraries mailing list
>         Libraries at haskell.org <mailto:Libraries at haskell.org>
>         http://www.haskell.org/__mailman/listinfo/libraries
>         <http://www.haskell.org/mailman/listinfo/libraries>
>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/