On 02/02/2017 15:56, Dmitry Soshnikov wrote:
On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat <walde...@google.com
<mailto:walde...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
