Open MasonProtter opened 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.
@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.
I'd be fine with making operator parsing whitespace dependent for these things.
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 oftenn↑
. 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.