Can we argue about the fixity for (<&>)? I've always it as infixl 4, to mix it in with other applicative operators, e.g.: (:) <$> fx <*> fl becomes fx <&> (:) <*> fl On Thu, Apr 17, 2014 at 2:05 PM, Clark Gaebel wrote:

Last I checked,

(&) = flip ($)

is both shorter to type, and more explicit than:

import Control.Apply.Reverse

- Clark

On Thu, Apr 17, 2014 at 2:03 PM, Hans Höglund wrote:

...

There is also is my humble attempt to standardize the (&) formulation:

http://hackage.haskell.org/package/reverse-apply

As you can see, these definitions now mirror those in 'lens' exactly. I see no reason why this definition should not move to base. IMHO, the Diagrams definition is a very specific one based on the needs of that EDSL, while the lens formulation is the expected one.

Mvh, Hans

On 17 apr 2014, at 14:00, haskell-cafe-request@haskell.org wrote:

Message: 1 Date: Wed, 16 Apr 2014 16:49:31 -0700 From: Dan Burton To: Alexey Muranov Cc: haskell-cafe Subject: Re: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) Message-ID: Content-Type: text/plain; charset="utf-8"

In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, this is (#) at infixl 8. You're certainly not the first to want this, but nobody can ever agree what it should be called or what fixity it should have. You can always just define it yourself.

-- Dan Burton

On Wed, Apr 16, 2014 at 3:25 PM, Alexey Muranov

...

wrote:

Hello,

i am completely new to Haskell, but i am somewhat fascinated by

lambda-calculus and programming.

For whatever it is worth, i would like to propose for discussion a syntax

for "(flip ($))" operation in Haskell.

I think that a good syntax would be "|^", for example:

square x = x * x

y = 3 |^ square -- y == 9

Explanation:

* i would have suggested just ^, but it would conflict with number

exponentiation,

* it is rather common in mathematics to write function application in

exponential notation: x ^ f instead of f(x), especially if f is an

automorphism of some structure,

* (flip ($)) is exactly the exponentiation of Church numerals,

* in "The calculi of lambda-conversion", Alonzo Church uses the

"shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms.

* I am probably not the only person missing the ability to apply functions

from the right:

http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-fo...

Well, other notations i've thought of are "\^" and "~$".

Alexey.

_______________________________________________

Haskell-Cafe mailing list

Haskell-Cafe@haskell.org

http://www.haskell.org/mailman/listinfo/haskell-cafe

The choice of fixity came about because actually the most common thing replaced by (<&>) is actually (>>=), when the thing you are binding to no longer has an effect, not actually (<$>), despite what the name suggests. This made a non-trivial difference in the amount of parentheses in real code, and was a conscious decision, so reverting it is not something I would do lightly and breaks real code. Back during the discussion of whether we should adopt (&), (<&>) also came up, but with only one voice in favor, and nobody else really feeling passionately, and with various colors like this available for the bikeshed it was dropped. -Edward On Thu, Apr 17, 2014 at 3:32 PM, Hans Höglund wrote:

Can we argue about the fixity for (<&>)? I've always it as infixl 4, to mix it in with other applicative operators, e.g.:

(:) <$> fx <*> fl

becomes

fx <&> (:) <*> fl

...

I agree, this seems to be a mistake in lens.

Last I checked,

...

(&) = flip ($)

is both shorter to type, and more explicit than:

import Control.Apply.Reverse

- Clark

Well the purpose here is to propose a standard name and fixity, not to save keystrokes.

When a lot of libraries start to define a (trivial) thing under different names, that to me is a good indication that it should be in the standard library. It is a matter of keeping the signal-to-noise ratio large, which greatly helps when reading unfamiliar code.

Hans

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

After the last time this made the rounds, this went to the core libraries committee. Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10. Done. -Edward Kmett -Edward On Thu, Apr 17, 2014 at 3:12 PM, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 17/04/14 20:05, Clark Gaebel wrote:

...

Last I checked,

(&) = flip ($)

is both shorter to type, and more explicit than:

import Control.Apply.Reverse There is no reason to use a library for making a reverse compose operator. The discussion should rather be whether this is worthwhile and interesting to add to prelude.

- -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF0EAREIAAYFAlNQJ5cACgkQRtClrXBQc7Ut3AD+LUk9sfgw73IL7agSHOf4dstg uJlKi7yUHTiX8RrYbdIA9R6DFKXr8BITDUFIjM1Q4kBM1umQdlfsuKF4a01nIs0= =WNYj -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

* (|) is already stolen for syntax, so the pairing, while a powerful mnemonic, can't be used at all here. * (#) collides with the use of (#) in MagicHash, so you get uncomfortable cases where you need to throw in a space. * (&) can be read off as "and then". (#) has no such obvious reading and is just more line noise someone has to learn. On Thu, Apr 17, 2014 at 4:02 PM, Alexey Muranov wrote:

On 17 avr. 2014, at 21:20, Edward Kmett wrote:

Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.

Why '&' and not '#', for example? I have an empression that '&' often comes in pair with '|' for Boolean operations.

Alexey.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, 18 Apr 2014 10:13:33 +0200, Alexey Muranov wrote:

On 17 avr. 2014, at 22:24, Edward Kmett wrote: Thanks for the explanation. Maybe some Wiki page with a list of syntax and fixity proposals, explanations, comments, and votes could be made for this?

One more idea: how about '>-' for 'flip ($)' and '-<' for '$', by analogy with '>>=' and '=<<'?

y = 3 >- \x -> x * x -- y == 9

Conflicts with ArrowSyntax

On 17 Apr 2014, at 20:20, Edward Kmett wrote:

After the last time this made the rounds, this went to the core libraries committee.

Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.

I would like to strongly oppose the theft of the (&) operator from general use. The proposal to put it in Data.Function, such that you need to know you are importing it, is OK, but it should never go into the Prelude. My general position is that there are very few single-character operator names left for ordinary programmers to use locally in their code. Given we now have more than twenty years usage of Haskell, I think it is pretty likely that people have made use of the flexibility to define their own operators for code that will never be widely shared. Taking away those operators from users, to become "standard", will only break old code. As a single datapoint, I grepped for uses of the & operator in our codebase at work, and found ~28,000 LoC where it is used. Regards, Malcolm

Hi all, This proposal comes up every 6-12 months or so. So far our decision has been "no". I don't think we should change that decision unless the circumstances for that decision has changed (I don't think they have.) We use this "don't reopen issues unless circumstances have changed" policy for HP package proposals*. I think it's a good policy, as it saves valuable community energy to discuss new things. If things have truly changed, we can of course have the discussion again. * We took the policy from Python's PEP proposal policy. -- Johan

On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 18/04/14 12:31, Johan Tibell wrote:

...

So far our decision has been "no". You are mistaken. Please see Edward's email.

«Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.»

A patch has been provided and a GHC ticket has been opened.

My apologies. I must have glanced over the details since I've seen '&' and '|>' proposed before on this list. Please link to the consensus email in the GHC ticket (I saw one of them got closed because it didn't.)

I didn't even notice that this discussion was on haskell-cafe. Ideally such discussions should be on libraries@, as people who only want to read about more important stuff can subscribe to only that list. On Fri, Apr 18, 2014 at 4:33 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

There's a concensus email? Im pretty sure most folks don't check cafe threads for rfcs :-)

On Friday, April 18, 2014, Johan Tibell wrote:

...

On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen < alexander@plaimi.net> wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 18/04/14 12:31, Johan Tibell wrote:

...

So far our decision has been "no". You are mistaken. Please see Edward's email.

«Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.»

A patch has been provided and a GHC ticket has been opened.

My apologies. I must have glanced over the details since I've seen '&' and '|>' proposed before on this list. Please link to the consensus email in the GHC ticket (I saw one of them got closed because it didn't.)

This was brought up again in one of these very long threads in the cafe that have happened 2-3 times now. Last time when this came up in October, I offered to submit it to the core libraries committee for review as the previous time it had come up it was fairly contentious, and I opted to abstain from expressing an opinion for or against due to my role in the previous proposal. I submitted it to core-libraries-committee@haskell.org. They reviewed it, and came down 4 in favor, 2 not commenting, after a bit of a bikeshedding discussion the existing name was picked, and the scope was declared limited to just putting it in Data.Function, and not including it in Prelude. We decided to wait until 7.10 to put it in since at the time 7.8 was happening "any day now". Now it has happened, so when the topic popped up again it was just a matter of implementing an existing resoution. I do, however, agree the discussion of submitting it should have happened on the libraries mailing list. -Edward Kmett -Edward On Fri, Apr 18, 2014 at 10:56 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

Indeed! (And while it looks like a Alex and Edward voted, not sure who else did :-) )

On Friday, April 18, 2014, Johan Tibell wrote:

...

I didn't even notice that this discussion was on haskell-cafe. Ideally such discussions should be on libraries@, as people who only want to read about more important stuff can subscribe to only that list.

On Fri, Apr 18, 2014 at 4:33 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

There's a concensus email? Im pretty sure most folks don't check cafe threads for rfcs :-)

On Friday, April 18, 2014, Johan Tibell wrote:

...

On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen < alexander@plaimi.net> wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 18/04/14 12:31, Johan Tibell wrote:

...

So far our decision has been "no". You are mistaken. Please see Edward's email.

«Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.»

A patch has been provided and a GHC ticket has been opened.

My apologies. I must have glanced over the details since I've seen '&' and '|>' proposed before on this list. Please link to the consensus email in the GHC ticket (I saw one of them got closed because it didn't.)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I agree. This is not going into Prelude. -Edward On Friday, April 18, 2014, Malcolm Wallace wrote:

On 17 Apr 2014, at 20:20, Edward Kmett wrote:

...

After the last time this made the rounds, this went to the core libraries committee.

Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.

I would like to strongly oppose the theft of the (&) operator from general use. The proposal to put it in Data.Function, such that you need to know you are importing it, is OK, but it should never go into the Prelude.

My general position is that there are very few single-character operator names left for ordinary programmers to use locally in their code. Given we now have more than twenty years usage of Haskell, I think it is pretty likely that people have made use of the flexibility to define their own operators for code that will never be widely shared. Taking away those operators from users, to become "standard", will only break old code.

As a single datapoint, I grepped for uses of the & operator in our codebase at work, and found ~28,000 LoC where it is used.

Regards, Malcolm _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/haskell-cafe