On Feb 5, 2014, at 9:30 PM, Michael Dyck wrote:

> When I take the ECMAScript grammar and expand its abbreviations as outlined
> in section 5.1.5, I get a grammar with lots of unreachable nonterminals
> (i.e., symbols that can't appear in any sentential form derived from Script
> or Module).
> 
> For instance, consider StrictFormalParameters. With its parameters Yield
> and GeneratorParameter, it expands to 4 nonterminals:
>    StrictFormalParameters
>    StrictFormalParameters_Yield
>    StrictFormalParameters_GeneratorParameter
>    StrictFormalParameters_Yield_GeneratorParameter
> (I use underscores to make the resulting names easier to read.)

I think I'll make the "_" part of the expansion defined in chapter 5.

> 
> In the unexpanded grammar, it's used in only 3 productions:
> 
> 14.2:
>    ArrowFormalParameters :
>        ( StrictFormalParameters )
> 
> 14.3:
>    MethodDefinition[Yield] :
>        PropertyName[?Yield] ( StrictFormalParameters ) { FunctionBody }
> 
> 14.4:
>    GeneratorMethod[Yield] :
>        * PropertyName[?Yield]
>        ( StrictFormalParameters[Yield,GeneratorParameter] )
>        { FunctionBody[Yield] }
> 
> The first two of these expand to productions that reference
>     StrictFormalParameters
> and the last one expands to productions that reference
>     StrictFormalParameters_Yield_GeneratorParameter.
> So
>     StrictFormalParameters_Yield and
>     StrictFormalParameters_GeneratorParameter
> are never referenced, and are thus unreachable.
> 
> Is this intentional? Or should StrictFormalParameters have a "?Yield"
> subscript in the 14.3 and 14.4 productions?

Yes, it's intentional.

The Yield parameter selects whether or not "yield" is treated as an identifier or as an operator symbol. "yield" is only treated as an operator if the yield parameter is present.
The GeneratorParameter  parameter, when present, tags the use of a production in the parameter list.  A yield operation doesn't work as part of an initializer or computed property name  in a generator function's parameter list because when parameter declarations are evaluated, the associated generator object is not yet in a yield-able state.  However, to avoid confusion, we want to disallow the use of  "yield" as an identifier throughout a generator function including the parameter list.  So, we parameterize StrictFormalParameters for generator functions and methods with [Yield, GeneratorParameter]. That parameter combination can be interpreted as  don't allow "yield" as an identifier but also don't allow it to be used as an operator.

We never use StrictFormalParameter_Yield because that would permit the actual use of the yield operator within a formal parameter initializer.

We never use [GeneratorParameter] by itself because that essentially means allow "yield" as an identifier and don't treat it as an operator.  That's redundant.

I should probably make a statement in section 5 that not all expansions are necessarily used.

14.3 is particularly interesting. consider:

"don't use strict";
function *() {
   return {
       [yield something] (yield) {yield = 0}
   }
}


Yield is validly treated a yield operator in determining the computed property name but is a regular identifier in parameter list and body of the nest function. 

> (And while we're in the
> neighborhood, should FunctionBody also have a "?Yield" subscript in those
> productions?) If not, why not?

No, generator-ness and use of the yield operator doesn't propagate to nested functions.
> 
> Similarly, I'm also wondering about the unreachability of
>    Statement_Yield

there is no statement context where yield is used as an operator but the return statement is not allowed.


>    Declaration_Yield_Default
>    BindingIdentifier_Default_Yield

There is no context where "default" can be bound as an identifier and "yield" can also be used as an operator.

Allen


> 
> -Michael
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

On Feb 5, 2014, at 9:30 PM, Michael Dyck wrote:

> (I use underscores to make the resulting names easier to read.)

I think I'll make the "_" part of the expansion defined in chapter 5.

> Is this intentional? Or should StrictFormalParameters have a "?Yield"
> subscript in the 14.3 and 14.4 productions?

Yes, it's intentional.

The Yield parameter selects whether or not "yield" is treated as an identifier or as an operator symbol. "yield" is only treated as an operator if the yield parameter is present.
The GeneratorParameter  parameter, when present, tags the use of a production in the parameter list.  A yield operation doesn't work as part of an initializer or computed property name  in a generator function's parameter list because when parameter declarations are evaluated, the associated generator object is not yet in a yield-able state.  However, to avoid confusion, we want to disallow the use of  "yield" as an identifier throughout a generator function including the parameter list.  So, we parameterize StrictFormalParameters for generator functions and methods with [Yield, GeneratorParameter]. That parameter combination can be interpreted as  don't allow "yield" as an identifier but also don't allow it to be used as an operator.

We never use StrictFormalParameter_Yield because that would permit the actual use of the yield operator within a formal parameter initializer.

We never use [GeneratorParameter] by itself because that essentially means allow "yield" as an identifier and don't treat it as an operator.  That's redundant.

I should probably make a statement in section 5 that not all expansions are necessarily used.

14.3 is particularly interesting. consider:

```js
"don't use strict";
function *() {
   return {
       [yield something] (yield) {yield = 0}
   }
}
```

Yield is validly treated a yield operator in determining the computed property name but is a regular identifier in parameter list and body of the nest function. 

> (And while we're in the
> neighborhood, should FunctionBody also have a "?Yield" subscript in those
> productions?) If not, why not?

No, generator-ness and use of the yield operator doesn't propagate to nested functions.
> 
> Similarly, I'm also wondering about the unreachability of
>    Statement_Yield

there is no statement context where yield is used as an operator but the return statement is not allowed.


>    Declaration_Yield_Default
>    BindingIdentifier_Default_Yield

There is no context where "default" can be bound as an identifier and "yield" can also be used as an operator.