Understanding static semantics

# raul mihaila (9 years ago)

Do sentences like "it's a syntax error if the LexicallyDeclaredNames of StatementList contains any duplicate entries" (section 15.1.1) refer to the result of applying the LexicallyDeclaredNames rule for a production alternative in which StatementList is the left-hand side nonterminal? If this is correct, then looking at LexicallyDeclaredNames for StatementList at some point we get to apply LexicallyDeclaredNames for Statement: "1. If Statement is Statement : LabelledStatement , return LexicallyDeclaredNames of Statement." (section 13.1.5). But I couldn't find a definition for LexicallyDeclaredNames where Statement is the lhs nonterminal. So in section 13.1.5 shouldn't it say "If Statement is Statement : LabelledStatement , return LexicallyDeclaredNames of LabelledStatement"?

Thank you.

# Michael Dyck (9 years ago)

On 15-03-06 06:46 AM, raul mihaila wrote:

Do sentences like "it's a syntax error if the LexicallyDeclaredNames of StatementList contains any duplicate entries" (section 15.1.1) refer to the result of applying the LexicallyDeclaredNames rule for a production alternative in which StatementList is the left-hand side nonterminal?

Yes, pretty much. Though I would word it: ... the result of applying the LexicallyDeclaredNames rule to the 'StatementList' child of the 'ScriptBody' node [that this early error rule is being applied to]

If this is correct, then looking at LexicallyDeclaredNames for StatementList at some point we get to apply LexicallyDeclaredNames for Statement: "1. If Statement is Statement : LabelledStatement , return LexicallyDeclaredNames of Statement." (section 13.1.5). But I couldn't find a definition for LexicallyDeclaredNames where Statement is the lhs nonterminal.

The production 'Statement : LabelledStatement' is what the spec calls a 'chain production' (5.1.1), so (according to 5.2), there's an implicit rule:

 Static Semantics: LexicallyDeclaredNames
 Statement : LabelledStatement
     1. Return LexicallyDeclaredNames of LabelledStatement

So in section 13.1.5 shouldn't it say "If Statement is Statement : LabelledStatement , return LexicallyDeclaredNames of LabelledStatement"?

Changing 'Statement' to 'LabelledStatement' there is not necessary, given the implicit rule. However, it seems simpler/clearer to me to avoid going through the implicit rule, so you could submit this as an 'enhancement' bug.

# Allen Wirfs-Brock (9 years ago)

On Mar 6, 2015, at 3:46 AM, raul mihaila wrote:

Do sentences like "it's a syntax error if the LexicallyDeclaredNames of StatementList contains any duplicate entries" (section 15.1.1) refer to the result of applying the LexicallyDeclaredNames rule for a production alternative in which StatementList is the left-hand side nonterminal? If this is correct, then looking at LexicallyDeclaredNames for StatementList at some point we get to apply LexicallyDeclaredNames for Statement: "1. If Statement is Statement : LabelledStatement , return LexicallyDeclaredNames of Statement." (section 13.1.5). But I couldn't find a definition for LexicallyDeclaredNames where Statement is the lhs nonterminal. So in section 13.1.5 shouldn't it say "If Statement is Statement : LabelledStatement , return LexicallyDeclaredNames of LabelledStatement"?

Thank you.

On of the Statement productions is Statement : LabelledStatement

15.3 defines a chain rule for associating algorithms with productions:

Unless explicitly specified otherwise, all chain productions have an implicit definition for every algorithm that might be applied to that production’s left-hand side nonterminal. The implicit definition simply reapplies the same algorithm name with the same parameters, if any, to the chain production’s sole right-hand side nonterminal and then returns the result.

So, LexicallyDeclaredNames for Statement is in this in this case actually equivalent to LexicallyDeclaredNames for LabelledStatement.

However, it would probably be clearer for step 1 to just say LabelledStatement instead of Statement.

BTW, the best place to raise issues like this is: bugs.ecmascript.org