Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

require space between < and unary operators? #25337

Closed
JeffBezanson opened this issue Dec 31, 2017 · 13 comments
Closed

require space between < and unary operators? #25337

JeffBezanson opened this issue Dec 31, 2017 · 13 comments
Labels
kind:breaking This change will break code needs decision A decision on this change is needed parser Language parsing and surface syntax

Comments

@JeffBezanson
Copy link
Sponsor Member

JeffBezanson commented Dec 31, 2017

This would allow us to add <- and <~ as operators (see e.g. #16985 (comment)). x<-1 for comparing x to -1 is arguably not good style.

We could add ~> now, which would only break applying bitwise not to the > operator (which is pretty silly, although !> is a different story :) ).

@JeffBezanson JeffBezanson added kind:breaking This change will break code needs decision A decision on this change is needed parser Language parsing and surface syntax labels Dec 31, 2017
@iblislin
Copy link
Member

iblislin commented Dec 31, 2017

and maybe let DocumentFormat.jl do the work of enforcing on space or popup warnig?

@stevengj
Copy link
Member

We have a lot of Unicode arrow operators now... do we really need another ascii-art “arrow”?

@oscardssmith
Copy link
Member

I feel like this could lead to really hard to detect errors when writing things like x<-5 if <- means something like = 0

@ararslan
Copy link
Member

FWIW <- was added almost exactly a year ago and was reverted exactly for the breakage it caused in simple and innocuous situations which in most languages are valid, e.g. 0<-1. In R <- is a holdover from APL-style arrow assignment in S, and many recent style guides for R discourage its use for assignment exactly due to this subtle confusion.

Given our multitude of Unicode arrows and the ease with which we allow entering Unicode symbols at the REPL and in editors, it seems unnecessary to me to add little gotchas in the parser just for the sake of having a couple of cute ASCII operators.

@JeffBezanson
Copy link
Sponsor Member Author

Interesting, there are still more Unicode arrows we need to add, in particular ⇜ and ⇝.

@stevengj
Copy link
Member

stevengj commented Jan 2, 2018

See also #23224. The elements of the Arrows block that are currently not parsed as operators are ↕↖↗↘↙↜↝↞↟↡↢↥↧↨↩↪↫↬↭↯↰↱↲↳↴↵↶↷↸↹↺↻↼↽↾↿⇀⇁⇂⇃⇄⇅⇆⇇⇈⇉⇊⇋⇌⇍⇐⇑⇓⇕⇖⇗⇘⇙⇚⇛⇜⇝⇞⇟⇠⇡⇢⇣⇤⇥⇦⇧⇨⇩⇪⇫⇬⇭⇮⇯⇰⇱⇲⇳ ... several of these should probably be added to our operators list.

@JeffreySarnoff
Copy link
Contributor

+1 for operator-izing ⇜ ⇝ ⇠ ⇡ ⇢ ⇣↥↧

@StefanKarpinski
Copy link
Sponsor Member

The left and right arrows are easy enough, the up and down ones need an appropriate precedence. We can always add more arrow operators in 1.x versions so this is not urgent.

@stevengj
Copy link
Member

stevengj commented Jan 4, 2018

@StefanKarpinski, adding these arrow operators in 1.x would be a breaking change. e.g. is currently parsed as an identifier because U+21dc is in category So (Symbol, Other).

@JeffBezanson
Copy link
Sponsor Member Author

I added several of those in #25360

@StefanKarpinski
Copy link
Sponsor Member

I was under the impression that we were treating characters that we might want to make into operators (like arrows) as invalid. Of that not the case, should we do that?

@JeffBezanson
Copy link
Sponsor Member Author

Yes, on master the whole arrows block was made invalid characters, some of which have now become operators. Identifying other characters that we might make into operators unfortunately has to be done one at a time in general.

@stevengj
Copy link
Member

stevengj commented Jan 4, 2018

Right, sorry, I wasn't checking master. On master the remaining non-operator arrows are ↖↗↘↙↟↡↥↧↨↭↯↰↱↲↳↴↵↶↷↸↹↺↻↾↿⇂⇃⇅⇈⇊⇑⇓⇕⇖⇗⇘⇙⇞⇟⇡⇣⇤⇥⇦⇧⇨⇩⇪⇫⇬⇭⇮⇯⇰⇱⇲⇳, and these are currently all invalid in identifiers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:breaking This change will break code needs decision A decision on this change is needed parser Language parsing and surface syntax
Projects
None yet
Development

No branches or pull requests

7 participants