Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Conal Elliott conal at conal.net
Thu Jul 14 18:38:52 UTC 2016 

Any recent thoughts on adding liftA4 and liftA5 to Control.Applicative?

On Sat, Nov 8, 2014 at 11:39 AM, Edward Kmett <ekmett at gmail.com> wrote:

> We have two competing tensions that have been guiding the work so far,
> which is scattered across a few dozen different proposals and patches in
> Phab and is alarmingly intricate to detail.
>
> We've generally been guided by the notion you suggest here. In the wake of
> the AMP, the 'M' suffix really comes to mean the minimal set of effects
> needed to get the effect. This lets us generalize large numbers of
> combinators in Control.Monad (e.g. when/unless/guard) to 'just work' in
> more contexts.
>
> However, we also have to balance this carefully against two other concerns:
>
> 1.) Not breaking user code silently in undetectable ways.
>
> This is of course the utmost priority. It guides much of the AMP,
> including the 'backwards' direction of most of the dependencies. e.g. The
> reality is a large number of folks wrote (*>) = (>>) in their code, so e.g.
> if we defined (>>) = (*>), we'd get a large chunk of existing production
> code that just turns into infinite loops. We can always do more later as we
> find it is safe, but "first do no harm."
>
> 2.) Not introducing rampant performance regressions.
>
> David Feuer has been spending untold hours on this, and his work there is
> a large part of the source of endless waves of proposals he's been putting
> forth.
>
> Considering `liftM2` as 'redundant' from `liftA2` can be dangerous on this
> front.
>
> The decision of if we can alias liftM3 to liftA3 needs to be at least
> *partially* guided by the question of whether the latter is a viable
> replacement in practice. I'm not prepared to come down on one side of that
> debate without more profiling data.
>
> Adding liftA4, liftA5 runs afoul of neither of these caveats. Aliasing
> liftMn to liftAn is something that *potentially* runs afoul of the
> latter, and is something that we don't have to do in a frantic rush. The
> world won't end if we play it safe and don't get to it in time for 7.10.
>
> -Edward
>
> On Sat, Nov 8, 2014 at 7:42 AM, Andreas Abel <abela at chalmers.se> wrote:
>
>> 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/
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160714/ad2e86f9/attachment-0001.html>

More information about the Libraries mailing list