Arrows Not Primary?
jason.orendorff at gmail.com
Mon Sep 24 07:32:38 PDT 2012
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
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
AdditiveExpression : AdditiveExpression + MultiplicativeExpression
RelationalExpression : RelationalExpression < ShiftExpression
ArrowFunction : ArrowParameters => ConciseBody
Two nonterminals with an operator between them. Thus when parsing `a
+ b < c` or `a => 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. :)
More information about the es-discuss