ecma262
ecma262 copied to clipboard
The nonterminals are the same
The following corresponding symbols are actually duplicates, one is an alias for the other, should it be unified into one symbol?
AsyncFunctionDeclaration
AsyncFunctionExpression
AsyncGeneratorDeclaration
AsyncGeneratorExpression
ClassDeclaration
ClassExpression
FunctionDeclaration
FunctionExpression
GeneratorDeclaration
GeneratorExpression
for examle:
FunctionDeclaration[Yield, Await, Default] :
`function` BindingIdentifier[?Yield, ?Await] `(` FormalParameters[~Yield, ~Await] `)` `{` FunctionBody[~Yield, ~Await] `}`
[+Default] `function` `(` FormalParameters[~Yield, ~Await] `)` `{` FunctionBody[~Yield, ~Await] `}`
FunctionExpression :
`function` BindingIdentifier[~Yield, ~Await]? `(` FormalParameters[~Yield, ~Await] `)` `{` FunctionBody[~Yield, ~Await] `}`
It's true that FunctionExpression derives exactly the same sublanguage as FunctionDeclaration[~Yield, ~Await, +Default]. So, as far as the grammar is concerned, we could delete the production for FunctionExpression and replace its only use (in PrimaryExpression) with FunctionDeclaration[~Yield, ~Await, +Default], and we would get the same language.
However, FunctionExpression and FunctionDeclaration have somewhat different semantics (e.g., see their Evaluation semantics), and I believe it would be difficult to maintain that difference if we made the above substitution.
(I think it's similar for the other examples.)
Thank you!Description semantics usually use a high-level language that has more tools than BNF, so it is recommended that let semantics try to accommodate BNF as much as possible rather than the other way around.
I have pretty much the opposite opinion: the BNF should accommodate the semantics as much as possible. The semantics are already massively complicated. They shouldn't be made even more complicated by switching to a grammar that is worse at supporting the semantics.