Arrows Not Primary?
Never mind - it's to prevent grammatical ambiguity in the concise form. Sorry for the noise.
Kevin,
Do you think this is something worth adding a "Note" entry to the spec for? If so, we should file a ticket
On Mon, Sep 24, 2012 at 7:55 AM, Kevin Smith <khs4473 at gmail.com> wrote:
Looking at the July 8 Draft, I notice that arrow functions are produced by AssignmentExpression, not PrimaryExpression (as function expressions are). Why is that? Is it to limit the operators that can be applied to them?
Kevin already said "disregard", but in case anyone else wants to know more...
FunctionExpressions have bookends--specific tokens at both the
beginning and the end. As soon as you see function in expression
context, you know you're parsing a FunctionExpression, and as soon as
you see the matching }, you know you're done. No lookahead is
required.
When an expression has bookends, you never have to worry about operator precedence to determine where one expression ends and the next one begins. Any production with bookends can be a primary without risk of ambiguity. (Example: Lisp doesn't have operator precedence; conveniently, all expressions in Lisp have bookends.)
The production for ArrowFunction looks more like the rest of the expression syntax: AdditiveExpression : AdditiveExpression + MultiplicativeExpression RelationalExpression : RelationalExpression < ShiftExpression ArrowFunction : ArrowParameters => ConciseBody
Two nonterminals with an operator between them. Thus when parsing `a
- b < c
ora => b < c` you need to know operator precedence. In the
JS standard, precedence is specified grammatically.
What precedence is best for =>? We definitely want a => a + 1 to
parse as a => (a + 1), not (a => a) + 1, so => must be
lower-precedence than +. Similar reasoning puts => lower than
==, lower even than ||. AssignmentExpression is where we end up.
We want a => b => a + b to parse as a => (b => (a + b), not `(a =>
b) => (a + b)or a SyntaxError, so=>` must be right-associative.
Conveniently, assignment operators already bind to the right.
Sorry for the noise.
Same here. :)
Looking at the July 8 Draft, I notice that arrow functions are produced by AssignmentExpression, not PrimaryExpression (as function expressions are). Why is that? Is it to limit the operators that can be applied to them?
When descent parsing, we have to drill down into primary expression to parse the "maybe-paren-expresion", so it's more straightforward to parse arrows there.