Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

[Eric Mertens]

For what it's worth, the liftA_ versions are suitable for partial
application. Additionally I tend to prefer liftA2 to reimplementing it each
time with <$> and <*> in the same way that I prefer sum to foldl' (+) 0,
liftA2 expresses my intent while f <$> x <*> y feels leaky. That's not to
say I never use it, but the operators certainly don't obviate the need for
the liftA_ combinators.

On Wed, Nov 5, 2014 at 11:20 PM, David Feuer <david.feuer at gmail.com> wrote:

> I don't feel strongly about it, but that seems like a reasonable plan.
>
> On Thu, Nov 6, 2014 at 1:31 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
>
>> David: I think the resistance you're seeing is coming from the fact that-
>> at least in my experience- liftMN is not considered good, idiomatic Haskell
>> code, since the idea is expressed *better* by <$> and <*>. There's been a
>> downside until now that <$> and <*> introduced a different constraint
>> (Applicative instead of Monad) but, as you already mention, AMP will solve
>> that.
>>
>> So- at least for me- adding in liftA2... would be a step *backwards*,
>> since it encourages people to avoid the idiomatic solution for the
>> non-idiomatic solution. In fact, I wouldn't be surprised if you'd get less
>> resistance to the idea of deprecating liftM2... (though please *don't*
>> propose that, there's no need to break backwards compatibility).
>>
>> But let me ask something else: why not just change the type signature of
>> liftM2... to have an Applicative constraint instead of a Monad constraint?
>> Besides the funny naming, that would seem to address your concern, without
>> increasing the number of non-idiomatic combinators.
>>
>> On Thu, Nov 6, 2014 at 6:44 AM, David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> Sure you could, but that would be kind of silly. liftMN should either be
>>> defined as liftAN or should be defined using the Monad ops as they have in
>>> the past. I was trying to make Base a little smaller by using the first
>>> approach, but it's not a big deal to repeat everything with specializations
>>> and unfoldings.
>>>
>>> On Wed, Nov 5, 2014 at 11:14 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> umm.... you can use  <*> to define the liftAN operations right?
>>>> Couldn't you just directly use <*> and pure to define the liftMN ones?
>>>>
>>>> On Wed, Nov 5, 2014 at 9:32 PM, David Feuer <david.feuer at gmail.com>
>>>> wrote:
>>>>
>>>>> Well, I'm looking to define  liftM = liftA, liftM2 = liftA2, liftM3 =
>>>>> liftA3, and (with a modified definition of ap) I'm getting that to work,
>>>>> but that leaves liftM4 and liftM5 hanging.
>>>>>
>>>>> On Wed, Nov 5, 2014 at 9:30 PM, John Lato <jwlato at gmail.com> wrote:
>>>>>
>>>>>> Does anyone actually want these?  I would have thought we should go
>>>>>> the other way and deprecate `liftM3+` in favor of using `<*>`.
>>>>>>
>>>>>> On Thu Nov 06 2014 at 10:26:36 AM David Feuer <david.feuer at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Since Applicative is supposed to be important now, I figure we
>>>>>>> should get these in.
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>


-- 
Eric Mertens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141106/ffa63b18/attachment-0001.html>