Within a generator body Arrow function formals treat yield as keyword but function declarations and expressions do not
Is this intentional? 14.1 Function Definitions --- FunctionDeclaration[Yield, Default] : function BindingIdentifier[?Yield] ( FormalParameters ) { FunctionBody } [+Default] function ( FormalParameters ) { FunctionBody } FunctionExpression : function BindingIdentifieropt ( FormalParameters ) { FunctionBody } --- 14.2 Arrow Function Definitions --- 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] ) --- Following the production rules for StrictFormalParameters and FormalParameters you can end up at SingleNameBinding SingleNameBinding[Yield, GeneratorParameter] : [+GeneratorParameter] BindingIdentifier[Yield] Initializer[In]opt [~GeneratorParameter] BindingIdentifier[?Yield] Initializer[In, ?Yield]opt This looks like it suggests following: var yield; function* gf() { function f(yield = yield) { } // valid parse, both yields are identifiers, second binds to the global var var f = function (yield = yield) { }; // same deal var a = (yield = yield) = { }; // first yield is treated as keyword, doesn't parse, second is treated as identifier and again binds to the global var } Binding to the global var in the default argument expressions is weird and perhaps confusing but acceptable I suppose. The inconsistency of the formal name treatment between functions and arrow functions feels wrong to me given that the formal names are created in non-generator scopes. Ian ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Specification of use before declaration errors
Wait, so is there no variable shadowing allowed then? 13.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors Static Semantics: Early Errors Block : { StatementList } * It is a Syntax Error if the LexicallyDeclaredNames of StatementList contains any duplicate entries. * It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the VarDeclaredNames of StatementList. StatementList can contain Blocks whose LexicallyDeclaredNames and VarDeclaredNames algorithms return the values for their StatementLists, so it recursively collects the names from all nested lexical and var declarations. It looks like VarDeclaredNames is missing a definition for VariableStatement because I can't see any way for the bound names of a VariableStatement to get added to VarDeclaredNames lists. But barring for the moment that I cannot find an algorithm definition that adds BoundNames of a VariableStatement to VarDeclaredNames, this second early error bullet implies that shadowing of bound names is not allowed at all. Is this correct? Ian From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Sent: Friday, November 8, 2013 4:16 PM To: Ian Halliday Cc: es-discuss@mozilla.org Subject: Re: Specification of use before declaration errors On Nov 8, 2013, at 3:35 PM, Ian Halliday wrote: Hello es-discuss, I'm having difficulty figuring out where the ES6 draft spec specifies that a use before declaration error should be thrown. My last understanding of the temporal dead zone was that ECMAScript would always issue a use before declaration error at runtime, regardless whether it can be statically determined or not. However it seems like the evaluation semantics of var declarations, for example, do not lead to any line that throws a ReferenceError. That is, consider this code: function f() { { var x = 5; let x; declaring the same name using a let and a var is an early error: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors or for the function level http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-early-errors } } f(); I think the var declaration creates a binding for x in the function's lexical environment, but then binds to the x in the block's environment for the initialization. As such, the initialization should throw a use before declaration error. But this is what I cannot find in the spec. Maybe I am wrong about the semantics here? because an early error exists, the surround script or module is never evaluated. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Specification of use before declaration errors
Oh, is shadowing a let declaration with a var declaration a syntax error? E.g. { let x; { var x; } } From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Ian Halliday Sent: Wednesday, November 13, 2013 4:14 PM To: Allen Wirfs-Brock Cc: es-discuss@mozilla.org Subject: RE: Specification of use before declaration errors Then for 13.1.8 shouldn't there be something like this StatementListItem : Statement 1. If Statement is a Block then return a new empty List. 2. Else return VarDeclaredNames of Statement defined in order to prevent the var names from spreading into enclosing blocks? I might be misunderstanding VarDeclaredNames. I am guessing that it should be a collection of all the names declared via var declaration statements, i.e. VariableStatement, but there isn't a definition of VarDeclaredNames for VariableStatement. 13.1.8http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-vardeclarednames Static Semantics: VarDeclaredNames See also: 13.0.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-statement-semantics-static-semantics-vardeclarednames, 13.5.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-if-statement-static-semantics-vardeclarednames, 13.6.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-do-while-statement-static-semantics-vardeclarednames, 13.6.2.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-while-statement-static-semantics-vardeclarednames, 13.6.3.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-for-statement-static-semantics-vardeclarednames, 13.6.4.3http://people.mozilla.org/~jorendorff/es6-draft.html#sec-for-in-and-for-of-statements-static-semantics-vardeclarednames, 13.10.2http://people.mozilla.org/~jorendorff/es6-draft.html#sec-with-statement-static-semantics-vardeclarednames, 13.11.4http://people.mozilla.org/~jorendorff/es6-draft.html#sec-switch-statement-static-semantics-vardeclarednames, 13.12.2http://people.mozilla.org/~jorendorff/es6-draft.html#sec-labelled-statements-static-semantics-vardeclarednames, 13.14.2http://people.mozilla.org/~jorendorff/es6-draft.html#sec-try-statement-static-semantics-vardeclarednames, 14.1.11http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-vardeclarednames, 14.4.10http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions-static-semantics-vardeclarednames, 14.5.14http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions-static-semantics-vardeclarednames, 15.1.0.12http://people.mozilla.org/~jorendorff/es6-draft.html#sec-module-semantics-static-semantics-vardeclarednames, 15.2.5http://people.mozilla.org/~jorendorff/es6-draft.html#sec-scripts-static-semantics-vardeclarednames. Block : { } 1. Return a new empty Listhttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-list-and-record-specification-type. StatementList : StatementList StatementListItem 1. Let names be VarDeclaredNames of StatementList. 2. Append to names the elements of the VarDeclaredNames of StatementListItem. 3. Return names. StatementListItem : Declaration 1. Return a new empty Listhttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-list-and-record-specification-type. From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Sent: Wednesday, November 13, 2013 3:49 PM To: Ian Halliday Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org Subject: Re: Specification of use before declaration errors On Nov 13, 2013, at 3:41 PM, Ian Halliday wrote: Wait, so is there no variable shadowing allowed then? this is saying that things like the following are illegal: {var x; let x; } But shadowing, like the following is fine: var x; {let x; } 13.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors Static Semantics: Early Errors Block : { StatementList } * It is a Syntax Error if the LexicallyDeclaredNames of StatementList contains any duplicate entries. * It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the VarDeclaredNames ofStatementList. StatementList can contain Blocks whose LexicallyDeclaredNames and VarDeclaredNames algorithms return the values for their StatementLists, so it recursively collects the names from all nested lexical and var declarations. It looks like VarDeclaredNames is missing a definition for VariableStatement because I can't see any way for the bound names of a VariableStatement to get added to VarDeclaredNames lists. But barring for the moment that I cannot find an algorithm definition that adds BoundNames of a VariableStatement to VarDeclaredNames, this second early error bullet implies that shadowing of bound names is not allowed at all. Is this correct? Ian From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Sent: Friday, November 8, 2013
Should arrow functions have arguments or capture arguments bindings
The draft spec has a note in 9.2.13 Function Declaration Instantiation about arrow functions and arguments: Issure: should concise methods also not get an arguments object? From rev16 it appears. Section 9.2.13 also has a large banner stating that it is old and will change re concensus made in the Sept 2013 TC39 meeting. I can't see any mention of arguments and arrow functions in the Sept 2013 meeting notes so is it safe to assume this behavior hasn't changed? Given the note is this still an open issue? If arguments is not added to the arrow function's var bindings, does this mean an arrow function should capture variables named arguments from the enclosing scope? E.g. function f () { var x = () = arguments; // captures f()'s implicit arguments { let arguments; var y = () = arguments; // captures lexical local variable } } Ian ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Specification of use before declaration errors
Hello es-discuss, I'm having difficulty figuring out where the ES6 draft spec specifies that a use before declaration error should be thrown. My last understanding of the temporal dead zone was that ECMAScript would always issue a use before declaration error at runtime, regardless whether it can be statically determined or not. However it seems like the evaluation semantics of var declarations, for example, do not lead to any line that throws a ReferenceError. That is, consider this code: function f() { { var x = 5; let x; } } f(); I think the var declaration creates a binding for x in the function's lexical environment, but then binds to the x in the block's environment for the initialization. As such, the initialization should throw a use before declaration error. But this is what I cannot find in the spec. Maybe I am wrong about the semantics here? If I am not wrong then this raises the question of order of operations. Is the RHS evaluated first, then the error is thrown? Or is the LHS name evaluated first, throwing if it is a binding that is currently in its TDZ? E.g. is g() called here before throwing? function g() { console.log('hello'); return 0; } function f() { { var x = g(); let x; } } f(); How about for-in/of loops? Is g() called here? function g() { console.log('hello'); return { a: 1, b: 2, c: 3 }; } function f() { { for (var x in g()) { console.log('unreachable'); } let x; } } Ian Halliday ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss