Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

David Feuer
Since Applicative is supposed to be important now, I figure we should get these in.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

John Lato-2
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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

David Feuer
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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Carter Schonwald
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

David Feuer
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Carter Schonwald
could you elaborate more on why it would be "silly"?
wouldn't defining things using <*> and pure be the way to make things simpler? Could you explain more please?

On Wed, Nov 5, 2014 at 11:44 PM, David Feuer <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries





_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Michael Snoyman
In reply to this post by David Feuer
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

David Feuer
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




--
Eric Mertens

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Henning Thielemann

On Thu, 6 Nov 2014, Eric Mertens wrote:

> 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.

I think I use liftM* and liftA* much more than <*>. They are really more
handy for partial application. Thus I would welcome liftA4 and liftA5.


Btw. I also avoid to use <$> together with <*>, but prefer

    pure f <*> a <*> b <*> c

because then every argument is matched with a <*>.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Henning Thielemann
In reply to this post by Michael Snoyman

On Thu, 6 Nov 2014, Michael Snoyman 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,

Who does not consider it good or idiomatic and why? Lifting things through
some stages of types is a common thing in Haskell, or not?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Henning Thielemann
In reply to this post by Eric Mertens

On Thu, 6 Nov 2014, Eric Mertens wrote:

> 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.


I like to add: liftA* and liftM* immediately put you back to the level of
plain function application. You can combine this easily with ($), (.) or
any other infix operator. In contrast to that, if you lift using (<*>),
($) would still require no extra parentheses, but (.) would.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Michael Snoyman
In reply to this post by Henning Thielemann


On Thu, Nov 6, 2014 at 11:50 AM, Henning Thielemann <[hidden email]> wrote:

On Thu, 6 Nov 2014, Michael Snoyman 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,

Who does not consider it good or idiomatic and why? Lifting things through some stages of types is a common thing in Haskell, or not?

I wasn't talking about lifting as a general concept, I was comparing to <$> and <*>. From what I've seen of Haskell code in general, people use the operators far more often, and tend to recommend them to new users.

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Andreas Abel-2
Agreed.  I never use liftMx or liftAx and when I see them in old code, I
replace them by <$> and <*>.

Anyway, I like the proposal best that changes to constraint on liftM to
Applicative, and leaves everything else alone.

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 [])

On 06.11.2014 11:04, Michael Snoyman wrote:

>
>
> On Thu, Nov 6, 2014 at 11:50 AM, Henning Thielemann
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>
>     On Thu, 6 Nov 2014, Michael Snoyman 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,
>
>
>     Who does not consider it good or idiomatic and why? Lifting things
>     through some stages of types is a common thing in Haskell, or not?
>
>
> I wasn't talking about lifting as a general concept, I was comparing to
> <$> and <*>. From what I've seen of Haskell code in general, people use
> the operators far more often, and tend to recommend them to new users.
>
> Michael
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Alexander Berntsen
In reply to this post by David Feuer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

(Sent this to David personally by a mistake.)


On 06/11/14 03:24, David Feuer wrote:
> Since Applicative is supposed to be important now, I figure we
> should get these in.
- -1.

On 06/11/14 07:31, Michael Snoyman wrote:
> 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.
I'd prefer just getting rid of liftMN, but this sounds like a
reasonable compromise.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRcnIEACgkQRtClrXBQc7V5HwEAryX1hJmfu4aLomGnOzEbVln1
webgdIhu6B2j4WB/zZMA/0f0Av5Bde/sC6KH1htcSABPo7Vv7gPcn5Yo03jHWVoK
=zn1W
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Henning Thielemann
In reply to this post by Andreas Abel-2

On Fri, 7 Nov 2014, Andreas Abel wrote:

> Agreed.  I never use liftMx or liftAx and when I see them in old code, I
> replace them by <$> and <*>.
>
> Anyway, I like the proposal best that changes to constraint on liftM to
> Applicative, and leaves everything else alone.

Ah no, this would add new stuff that can only be explained by history.


> 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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Jacques Carette
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Edward Kmett-2
In reply to this post by David Feuer
+1 from me, just for symmetry.

On Wed, Nov 5, 2014 at 9:24 PM, David Feuer <[hidden email]> wrote:
Since Applicative is supposed to be important now, I figure we should get these in.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Edward Kmett-2
In reply to this post by John Lato-2
If you want to partially apply a lifted function the f <$> x <*>y <*> z approach doesn't work.

liftMn and liftAn still have a place.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5

Carter Schonwald
ok, i amend my stance to be weakly +1

On Fri, Nov 7, 2014 at 1:00 PM, Edward Kmett <[hidden email]> wrote:
If you want to partially apply a lifted function the f <$> x <*>y <*> z approach doesn't work.

liftMn and liftAn still have a place.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12