Perfect.

           -- Cyrus

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Friday, November 14, 2014 9:21 AM
To: Cyrus Najmabadi
Cc: Jason Freeman; es-discuss list
Subject: Re: Grammar question about ArrowFormalParameters


On Nov 13, 2014, at 7:53 PM, Cyrus Najmabadi wrote:


Specifically, while the spec says that :

                SomeProd[Yield,GeneratorParameter]

Is equivalent to:

1)      SomeProd
2)      SomeProd_Yield
3)      SomeProd_GeneratorParameter
4)      SomeProd_Yield_GeneratorParameter

It's doesn't seem like it is actually possible for any path of productions from 
the root to ever end with "3) SomeProd_GeneratorParameter".  Whereas we can see 
paths to every other production.

Does that match your expectation?  If not, what's a path that could lead to 
such a state.

Yes, that's right.  As a grammar production, "Yield" means that `yield` is to 
be interpreted as the yield keyword and not as an identifier. 
"GeneratorParameter" means that the context of the parameterized prodution is 
the formal parameter list of a generator function.  The 
[Yield,GeneratorParameter]] production is used for situations where `yield` 
should not be treated as an identifier but where use of the yield operator is 
also illegal.  The only such situation is the formal parameter list of 
generator functions.

It is never the case that the context is the formal parameter list of a 
generator and `yield` is treated as an identifier.

Allen






Thanks!

         -- Cyrus

From: Jason Freeman
Sent: Thursday, November 13, 2014 7:10 PM
To: Cyrus Najmabadi; Allen Wirfs-Brock
Cc: es-discuss list
Subject: RE: Grammar question about ArrowFormalParameters

Thanks Allen for answering all of our questions. I have a theory that I wanted 
to run by you. It seems that the Yield and GeneratorParameter flags as a pair 
have only 3 possible states:
*         Yield and GeneratorParameter are both on
*         Yield and GeneratorParameter are both off
*         Yield is on, but GeneratorParameter is off

Would you say that is correct?

Thanks,
Jason

From: Cyrus Najmabadi
Sent: Thursday, November 13, 2014 4:45 PM
To: Allen Wirfs-Brock
Cc: Jason Freeman; es-discuss list
Subject: RE: Grammar question about ArrowFormalParameters

That seems reasonable* Allen.

And I appreciate confirmation that our reading of the spec is in line with 
yours.

           -- Cyrus

* I personally prefer the approach that moving to new language constructs may 
come with additional restrictions that are more onerous.  But that's just me.  
For example, I don't mind that Classes force 'strict mode' within them, and 
that you would not be able to copy "function (yield) { }" from outside the 
class to inside a class method.  But that's just me.  It wouldn't be javascript 
if there wasn't lots of fun complexity for us compiler writers :)

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Thursday, November 13, 2014 3:57 PM
To: Cyrus Najmabadi
Cc: Jason Freeman; es-discuss list
Subject: Re: Grammar question about ArrowFormalParameters


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<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions-static-semantics-early-errors>
 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

Reply via email to