inconsistent .op parsing for unicode operators

[stevengj]

As discussed on the mailing list, there is an annoying inconsistency in the parser:

julia> parse("5.≤x")
:(5.0 ≤ x) 

julia> parse("5.<=x") 
:(5 .<= x)

It would be nice to fix this by modifying the parser to treat . followed by any Unicode operator in the same way, so that we get "dot" versions of all the Unicode operators rather than having to manually add each operator twice. See also #6929 (comment)

[jakebolewski]

As noted on the mailing list this particular example is due to julia's space sensative parsing but operations like:

julia> parse("5 .⊕  10")
ERROR: ParseError("extra token \"10\" after end of expression")
 in parse at string.jl:1257
 in parse at string.jl:1267

could be parsed correctly.

[stevengj]

@jakebolewski, look at the example more closely. The problem is not that it is space-sensitive, the problem is that .≤ and .<= are treated differently.

.⊕ is different because it is not treated as an operator at all, regardless of spacing. Although this is a separate problem, my feeling is that the fix is to parse .op consistently regardless of op, and that solution will kill two birds with one stone.

[jakebolewski]

I've added the missing unicode operators that were special cased by the parser in 1101086. I agree a more general solution would be nice.

[tkelman]

backport pending label for 1101086 - it's harder to lose track of as an issue label than a commit comment

[stevengj]

Closing this, as the immediate inconsistency is fixed. If people want more dot parsing of unicode operators (not to mention operators with combining characters like +̂), that can be a separate issue.

[tkelman]

backported in 68d11e4, and tests in a09b2fa