On Nov 13, 2014, at 3:21 PM, Cyrus Najmabadi wrote:
> Hey Allen,
>
> We have a followup question. This time it’s more about understanding the
> rationale behind things, rather than asking what the spec is explicitly
> stating.
>
> Specifically, I’m curious why the spec says this in “14.2.1 Static Semantics:
> Early Errors”:
>
> If the [Yield] grammar parameter is present for
> CoverParenthesizedExpressionAndArrowParameterList[Yield] return the result of
> parsing the lexical token stream matched by
> CoverParenthesizedExpressionAndArrowParameterList[Yield] using
> ArrowFormalParameters[Yield, GeneratorParameter] as the goal symbol
>
> Instead of:
>
> If the [Yield] grammar parameter is present for
> CoverParenthesizedExpressionAndArrowParameterList[Yield] return the result of
> parsing the lexical token stream matched by
> CoverParenthesizedExpressionAndArrowParameterList[Yield] using
> ArrowFormalParameters as the goal symbol
This would permit:
function *g() {
yield (yield) => 42;
}
Because 'yield' is an identifier if ArrowFormalParameters isn't parameterized
with [Yield]. Because arrow functions are syntactically so tightly integrated
into expressions I didn't think it would be a good idea to allow that usage.
>
>
> Your example seems to exemplify the issue, but we’re not sure we understand
> why arrow function are treated this way. For example, you say (and we agree)
> that this should be illegal as per the spec:
>
> var yield = 42;
> function *g() {
> var f = (arg=yield) => arg; //it is a syntax error to use 'yield' within
> an arraw parameter list inside a generator function
> yield f();
> }
>
> However, it appears as if the following would be legal:
>
> var yield = 42;
> function *g() {
> var f = function (arg=yield) { return arg;}
> yield f();
> }
>
yes, this is legal. It is JS legacy that 'yield' is a regular identifier (not
a reserved word) in non strict mode code. We've tried to minimize the number
of "micro-modes" so we didn't add additional special cases to make things like
the above illegal. The function keyword strongly delimits the start of a new
function definition. Identical rules are applied to all non-strict
FunctionDeclaration and FunctionExpressions . We special case arrow functions
because they lack that strong syntactic delimiter and seem more like part of
the enclosing expression. Basically, definitions starting with 'function' can
be though of as self-contained entities.
> This is because of the following rule:
>
> FunctionExpression : See 14.1
> function BindingIdentifieropt ( FormalParameters ) { FunctionBody }
>
> Which explicitly does not use [Yield] or [Generatorparameter] on the
> FormalParameters.
>
> 1) do you think that code should be legal or not. If not, what part of
> the spec does make it illegal?
> 2) If it is legal, do you think that Arrow Functions and normal function
> expressions should behave differently here? If so, why?
see above
Allen
>
> Thanks!
>
> -- Cyrus
>
>
>
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Cyrus
> Najmabadi
> Sent: Thursday, November 13, 2014 2:45 PM
> To: Allen Wirfs-Brock
> Cc: Jason Freeman; es-discuss list
> Subject: RE: Grammar question about ArrowFormalParameters
>
> Hi Allen,
>
> I see. This was the part that was missed:
>
> If the [Yield] grammar parameter is present for
> CoverParenthesizedExpressionAndArrowParameterList[Yield] return the result of
> parsing the lexical token stream matched by
> CoverParenthesizedExpressionAndArrowParameterList[Yield] using
> ArrowFormalParameters[Yield, GeneratorParameter] as the goal symbol
>
> That does clear up the grammar question.
>
> Thanks much!
>
> -- Cyrus
>
>
>
> From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
> Sent: Thursday, November 13, 2014 2:25 PM
> To: Cyrus Najmabadi
> Cc: es-discuss list; Jason Freeman
> Subject: Re: Grammar question about ArrowFormalParameters
>
>
> On Nov 12, 2014, at 4:46 PM, Cyrus Najmabadi wrote:
>
>
> Hey ES6ers,
>
> I’m currently implementing some of the ES6 support for the next version of
> TypeScript. The part I’m looking at right now is generators and yield
> expressions. So far we feel fairly comfortable with the grammar and
> understand the implications of the [Yield] and [GeneratorParameter]. One
> spec issue that is getting us to scratch our heads though is this section:
>
> When the production
> ArrowParameters[Yield] :
> CoverParenthesizedExpressionAndArrowParameterList[?Yield]
>
> is recognized the following grammar is used to refine the interpretation of
> CoverParenthesizedExpressionAndArrowParameterList:
>
> ArrowFormalParameters[Yield, GeneratorParameter] :
> ( StrictFormalParameters[?Yield, ?GeneratorParameter] )
>
> The issue relates to the [GeneratorParamater] parameter on
> ArrowFormalParameters. We can’t see any path through the grammar that could
> ever end up enabling this parameter. While
> CoverParenthesizedExpressionAndArrowParameterList picks up the ‘yield’
> parameter from ArrowParameters, there seems to be nothing related to
> ‘GeneratorParameter’.
>
> See static semantic rules of
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions-static-semantics-early-errors
> and the second algorithm
> inhttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-static-semantics-coveredformalslist
>
>
>
> We also find the presence of this grammar parameter here to be somewhat odd
> as arrow function can’t be generators.
>
> It is dealing with code such as this:
>
> var yield = 42;
> function *g() {
> var f = (arg=yield) => arg; //it is a syntax error to use 'yield' within
> an arraw parameter list inside a generator function
> yield f();
> }
>
>
> Is this an issue with the spec? Or is there some subtlety here that we’ve
> missed that enables this parameter?
>
> It's subtle.
>
> Allen
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
