I think this would get more readers with a different title. I read it only because I know Bocoup do interesting stuff, but otherwise I would have assumed it was just some ill-informed rant about this this keyword.
It looks like the author was assuming that noticing the => token could be done with the LR(1) lookahead; that’s what the sequence of steps would look like if it worked that way. There might be an empty production immediately after the left-paren, and reducing it would go from “there’s an expression or something coming” to “there’s a list of formal parameters coming” without advancing the input. But from my read of the grammar, that’s not what happens - and it can’t, because, just like the author’s main example, you’d actually need a variable number of lookahead tokens to disambiguate these cases.
Instead, there’s a single nonterminal, CoverParenthesizedExpressionAndArrowParameterList, which parses both parenthesized expressions and the bindings for arrow functions. I believe the “supplemental syntax” note in 14.2 Arrow Function Definitions is obliquely describing reinterpreting this ambiguous intermediate type as a list of parameters.
This is great! Coherent explanations of how LR grammars actually work are really rare, and this one is motivated by something that really came up. It’s to-the-point and comprehensible.
I think this would get more readers with a different title. I read it only because I know Bocoup do interesting stuff, but otherwise I would have assumed it was just some ill-informed rant about this
thiskeyword.This would be a great use of our new
plttag!The TC39 meeting mentioned in the article has now taken place. Here are the discussion notes: http://tc39.github.io/tc39-notes/2017-11_nov-29.html#9iik-grammar-constraints
To cut to the chase: the resolution was to “chase with Brendan, Waldemar for their feedback.”
Incidentally, this meeting also discussed pipelines for Stage 2! yay! (But haven’t yet advanced it to Stage 2.)
How is the arrow function parsed without lookahead?
Both of these parentheses look identical:
How does the author know that “this is an arrow function” and not a nested parenthesized expression?
Nice catch.
It looks like the author was assuming that noticing the
=>token could be done with the LR(1) lookahead; that’s what the sequence of steps would look like if it worked that way. There might be an empty production immediately after the left-paren, and reducing it would go from “there’s an expression or something coming” to “there’s a list of formal parameters coming” without advancing the input. But from my read of the grammar, that’s not what happens - and it can’t, because, just like the author’s main example, you’d actually need a variable number of lookahead tokens to disambiguate these cases.Instead, there’s a single nonterminal,
CoverParenthesizedExpressionAndArrowParameterList, which parses both parenthesized expressions and the bindings for arrow functions. I believe the “supplemental syntax” note in 14.2 Arrow Function Definitions is obliquely describing reinterpreting this ambiguous intermediate type as a list of parameters.This is great! Coherent explanations of how LR grammars actually work are really rare, and this one is motivated by something that really came up. It’s to-the-point and comprehensible.