parsing issues with unary operators followed by (

[andyferris]

I made a typo (-+ instead of .+) and I found the result very surprising:

julia> :(1 -+ (a=1, b=2))
:(1 - ((a = 1) + (b = 2)))

julia> 1 -+ (a=1, b=2)
-2

I don't know where to start... it's just so... so...

(Happens on v0.7 and v0.6. EDIT: to be clear, I really expected the parser to greedily create a NamedTuple before worrying about the operators).

[andyferris]

We also forgot to treat operators as functions with the "no space between functions and (" rule

julia> + (1, 2)
3

I expect the same behavior as

julia> f (1, 2)
ERROR: syntax: space before "(" not allowed in "f ("

[JeffBezanson]

Yeah... what's happening is there's an ambiguity between parsing +(x) as a unary operator applied to a parenthesized expression, vs. as a 1-argument prefix function call form. We've been resolving it as the former. I think it would probably be good to switch to the latter, but we need to think through the implications.

[andyferris]

There's a comma in these examples, though - I don't feel these count as "parenthesized expressions" but rather tuple and named tuple literals.

One thing which I find confusing is that +(1, 2) becomes a function call to + with two positional arguments, yet +(a=1, b=2) is not a function call to + with two keyword arguments. I'm struggling to find what the unifying logic here is.

In the former scheme maybe there should also be a difference between + (x) and + (x,) (note the space). The former working out as calling + with x and the latter with calling + with a tuple, (x,). Without the space it is ambiguous, I have less of a strong opinion here except to point out that if deleting that space changes behavior that could be surprising, and if adding brackets around + changes behaviour that could also be surprising, so I have no idea:

(+)(1, 2)  # Function call - call `+` with two arguments, `1` and `2`
+ (1, 2)   # Unary operator on a tuple - call `+` with one argument, `(1, 2)`
+(1, 2)    # Could be either, or a parsing ambiguity error

Also, the last one is a valid way of defining a method on (the function) +.

Parsing issues get confusing, fast...

[JeffBezanson]

See #12771. The tricky case is -(x)^y, which should parse like -(x^y). That means -(x) can't be interpreted as function call syntax, since then it would have higher precedence than ^.

Applying a unary operator to a tuple is not useful, so I don't see it helping to parse +(2,) that way.

We can patch up +(a=1, b=2) to call + with keyword arguments. But there are still other weird cases (discussed in the linked issue) like +((1,2)).

I'll try to come up with something. I think we should prefer to treat +( ... ) as prefix function call syntax, unless it's followed by ^ and the ( ) part is just a parenthesized expression (no commas).