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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
