JuliaLang / julia

The Julia Programming Language
https://julialang.org/
MIT License
45.32k stars 5.45k forks source link

Remove \uparrow and \downarrow from infix operator list? #31639

Open MasonProtter opened 5 years ago

MasonProtter commented 5 years ago

Currently (\uparrow) and (\downarrow) are parsed as infix operators, so they can't be used in variable names, but I think they may be more useful in variable names than they would be as infix operators.

might be used to create Knuth's up arrow notation but even then, I think one might rather just put a unicode modifier on ^ instead of use and I've never seen such use in the wild. Conversely, I know that and are widely featured in the notation used by condensed matter physicists and quantum computing people to signify spin up and spin down. Ie. a spin up number operator is often n↑. Or sometimes one denotes a basis state vector simply as ↑ = [1, 0], ↓ = [0, 1].

So my proposal is that for julia version 2.0, we remove and from the infix operator list and instead treat them as regular unicode characters.

stevengj commented 5 years ago

This seems reasonable to me, but Julia 2.0 is a long way out and it might be too disruptive by then. There's also the fact that we parse pretty much all other arrows as operators, so it's not clear what the rule should be if we start making some of them ordinary identifiers.

MasonProtter commented 5 years ago

@StefanKarpinski suggested I file this as a 2.0 issue and I figured that makes sense since it is a non-essential breaking change, but I'll leave that up to the experts.

Dealing with other arrows does seem kinda tricky. I definitely see the utility in having and remain as infix operators since they are notationally very suggestive, since the arrow is actually pointing at a variable in the expression. Hell, someone might want to just alias const → = => because it's prettier and I don't think that should be disallowed.

What to do about the various different versions of \uparrow and downarrow is more subjective. On one hand, you can say it'd be more consistent to treat all those variants the same but on the other hand, people who really want to use \uparrow as an infix operator might be appeased if they're still allowed to use (\Uparrow) or some other variant.

Keno commented 5 years ago

I'd be fine with making operator parsing whitespace dependent for these things.