LR(1) grammar/parser and lookahead-restrictions

[Waldemar Horwat]

On 02/02/2017 15:56, Dmitry Soshnikov wrote:
> On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat <waldemar at google.com <mailto:waldemar at google.com>> wrote:
>
>     On 02/01/2017 10:25, Dmitry Soshnikov wrote:
>
>         As mentioned, Cover grammar is usually the process of the grammar design itself (as in ES6 spec itself). I'm not aware of automatic transformations for this (if you find any please let me know).
>
>
>     Cover grammars are an ugly hack that we had to add when there was no other practical choice.  Avoid them as much as possible.  They are only used in situations where lookahead restrictions and parametrized grammar rules do not work in any practical way.
>
>
> Yeah, absolutely agreed. The reason why I used cover grammar in that example to parse `{` as a `Block` vs. `ObjectLiteral`, and handle `ExpressionStatement` is to make the resulting grammar short, and don't introduce a bunch of `NoCurly`, etc extra productions for this. That's also said, this ugly hack also forces you to do post-processing overhead -- either validation of the nodes, or even re-interpretation (rewriting) to other nodes -- in my case I have to actually check that all nodes between `{` and `}` are properties, or vice-versa, statements, based on the expression/statement position.

Don't use a cover grammar to unify blocks with object literals.  That's a really bad idea and you'll likely get it wrong.  If the `{` starts a block, then if the next token is a keyword such as `if` then it's parsed as a keyword.  If the `{` starts an object literal, then if the next token is a keyword then it's parsed as an identifiername.  As we extend the language, the expansions of these can later diverge to the point where you won't know whether a `/` starts a regular expression or is a division symbol.

     Waldemar