1. 22
  1. 8

    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.

    1. 6

      This would be a great use of our new plt tag!

      1. 3

        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.)

        1. 2

          How is the arrow function parsed without lookahead?

          Both of these parentheses look identical:

          (: This is a parenthesized expression. Now expecting an expression

          (: This is an arrow function. Now expecting a list of bindings

          How does the author know that “this is an arrow function” and not a nested parenthesized expression?

          1. 3

            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.

          2. 2

            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.