Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
Edward Kmett
ekmett at gmail.com
Fri Nov 7 19:35:57 UTC 2014
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> 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>
> 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>
>> 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
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> 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/20141107/fa579ade/attachment-0001.html>
More information about the Libraries
mailing list