Editorial: <5.1.5 Grammar Notation> production parameterization example mistakes?

[jmm]

In the examples for parameterizing a nonterminal on the right-hand side in the ES2015 spec, I think there are a couple of mistakes, but perhaps I'm misunderstanding something.

1. :

   References to nonterminals on the right-hand side of a production can also be parameterized. For example:

     StatementList :
       ReturnStatement
       ExpressionStatement[In]
   

   is equivalent to saying:

     StatementList :
       ReturnStatement
       ExpressionStatement_In
   

   Isn't that actually equivalent to this?:

   StatementList :
     ReturnStatement
     ExpressionStatement
     ExpressionStatement_In
   

2. :

   A nonterminal reference may have both a parameter list and an “opt” suffix. For example:

   VariableDeclaration :
     BindingIdentifier Initializer[In]opt
   

   is an abbreviation for:

   VariableDeclaration :
     BindingIdentifier
     BindingIdentifier Initializer_In
   

   Isn't that actually an abbreviation for?:

   VariableDeclaration :
     BindingIdentifier
     BindingIdentifier Initializer
     BindingIdentifier Initializer_In
   

If this is correct I might be able to PR it later, but I got an error when I tried to build and haven't debugged it.

Also, I don't actually see ExpressionStatement[In] in the grammar -- if that's correct it'd be better to use a real example, right?

[bterlson]

The spec is correct. To start, note that

ExpressionStatement[In] :
    ...

is equivalent to two productions:

ExpressionStatement:
    ...

ExpressionStatement_In:
    ...

When a non-terminal is on the RHS, it must refer unambiguously to one of those productions. It does so using the following conventions:

// assume we have an in param here, which doesn't actually exist.
StatementList[In] :
   ExpressionStatement[In] // equivalent to ExpressionStatement_In
   ExpressionStatement[?In] // Refers to ExpressionStatement_In if In is passed to StatementList, otherwise ExpressionStatement

You are right that ExpressionStatement doesn't take an In parameter. The example is illustrative only, but if you want to dig out a better example from somewhere in the grammar I'd happily accept it!

[bterlson]

The spec is correct. To start, note that

ExpressionStatement[In] :
    ...

is equivalent to two productions:

ExpressionStatement:
    ...

ExpressionStatement_In:
    ...

When a non-terminal is on the RHS, it must refer unambiguously to one of those productions. It does so using the following conventions:

// assume we have an in param here, which doesn't actually exist.
StatementList[In] :
   ExpressionStatement[In] // equivalent to ExpressionStatement_In
   ExpressionStatement[?In] // Refers to ExpressionStatement_In if In is passed to StatementList, otherwise ExpressionStatement

You are right that ExpressionStatement doesn't take an In parameter. The example is illustrative only, but if you want to dig out a better example from somewhere in the grammar I'd happily accept it!

[jmm]

Thanks @bterlson! Sorry for the noise.

:
   ExpressionStatement[In] // equivalent to ExpressionStatement_In

That's a bit counterintuitive to me, but I believe I get it now: the point of parameterizing the RHS is to be able to use the notation Whatever[A, B] instead of needing 2 separate lines (literal symbols), and I assume it's favored even in the single-parameter case (like the example) because that way the notation looks the same as when the symbol is the LHS of a production.

Would you be open to the prose spelling that out a bit more? If I'm the only one that had a hard time with this, I digress.

You are right that ExpressionStatement doesn't take an In parameter. The example is illustrative only, but if you want to dig out a better example from somewhere in the grammar I'd happily accept it!

I like:

ExportDeclaration :
    export default HoistableDeclaration[Default]

It's a case with no parameter on LHS and only a single parameter on RHS, like the current illustration. And if you understand the semantics it also helps to illustrate that the parameter only "expands" to a single symbol.

If that sounds good I could try a PR -- it seems the build script runs for me now.

[jmm]

Thanks @bterlson! Sorry for the noise.

:
   ExpressionStatement[In] // equivalent to ExpressionStatement_In

That's a bit counterintuitive to me, but I believe I get it now: the point of parameterizing the RHS is to be able to use the notation Whatever[A, B] instead of needing 2 separate lines (literal symbols), and I assume it's favored even in the single-parameter case (like the example) because that way the notation looks the same as when the symbol is the LHS of a production.

Would you be open to the prose spelling that out a bit more? If I'm the only one that had a hard time with this, I digress.

You are right that ExpressionStatement doesn't take an In parameter. The example is illustrative only, but if you want to dig out a better example from somewhere in the grammar I'd happily accept it!

I like:

ExportDeclaration :
    export default HoistableDeclaration[Default]

It's a case with no parameter on LHS and only a single parameter on RHS, like the current illustration. And if you understand the semantics it also helps to illustrate that the parameter only "expands" to a single symbol.

If that sounds good I could try a PR -- it seems the build script runs for me now.

[ljharb]

@jmm are you interested in making a PR for this?

[ljharb]

@jmm are you interested in making a PR for this?

[jmdyck]

(Note that the notation has changed slightly since this issue was raised.)

(Also, HoistableDeclaration now takes 3 parameters.)

[jmdyck]

(Note that the notation has changed slightly since this issue was raised.)

(Also, HoistableDeclaration now takes 3 parameters.)