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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
