LR(1) grammar/parser and lookahead-restrictions

[Waldemar Horwat]

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.

When designing the grammar, the preferences are:

- Use standard LR(1) productions
- Use parametrized productions
- Use lookahead restrictions if parametrized productions would introduce too many parameters into rules
- Use a cover grammar if the grammar can't be reasonably expressed in any other way.  They're a last resort with lots of problems.

Lookahead restrictions fit very well into an LR(1) engine as long as they're limited to only one token, and that's what I've implemented in the validator.  You need to be very careful with them if looking more than one token ahead because lexing of the tokens can vary based on context.  For example, if the next few characters in front of the cursor are )/abc/i+, then what is the second token?  What is the third token?  It's actually context-dependent.

The same problem is even worse for cover grammars.

     Waldemar