Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Edward Kmett ekmett at gmail.com
Thu Jul 14 19:07:48 UTC 2016 

Given the long discussion we've had here, I'll make a call from the
standpoint of the CLC and say we'd happily accept a patch that added them.

-Edward

On Thu, Jul 14, 2016 at 2:38 PM, Conal Elliott <conal at conal.net> wrote:

> 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/f41babd4/attachment.html>

More information about the Libraries mailing list