[Python-Dev] PEP 492 vs. PEP 3152, new round

[Greg Ewing]

Nathaniel Smith wrote:
> Even if we put aside our trained intuitions about arithmetic, I think
> it's correct to say that the way unary minus is parsed is: everything
> to the right of it that has a tighter precedence gets collected up and
> parsed as an expression, and then it takes that expression as its
> argument.

Tighter or equal, actually: '--a' is allowed.

This explains why Yury's syntax disallows 'await -f'.
The 'await' operator requires something after it, but
there's *nothing* between it and the following '-',
which binds less tightly.

So it's understandable, but you have to think a bit
harder.

Why do we have to think harder? I suspect it's because
the notion of precedence is normally introduced to resolve
ambiguities. Knowing that infix '*' has higher precedence
than infix '+' tells us that 'a + b * c' is parsed as
'a + (b * c)' and not '(a + b) * c'.

Similarly, knowing that infix '.' has higher precedence
than prefix '-' tells us that '-a.b' is parsed as
'-(a.b)' rather than '(-a).b'.

However, giving prefix 'await' higher precedence than
prefix '-' doesn't serve to resolve any ambiguity.
'- await f' is parsed as '-(await f)' either way, and
'await f + g' is parsed as '(await f) + g' either way.

So when we see 'await -f', we think we already know
what it means. There is only one possible order for
the operations, so it doesn't look as though precedence
comes into it at all, and we don't consider it when
judging whether it's a valid expression.

What's the conclusion from all this? I think it's
that using precedence purely to disallow certain
constructs, rather than to resolve ambiguities, leads
to a grammar with less-than-intuitive characteristics.

-- 
Greg