On Mon, Oct 22, 2012 at 12:43 PM, Mark S. Miller <[email protected]> wrote:
> On Mon, Oct 22, 2012 at 5:27 AM, Rick Waldron <[email protected]>wrote: > >> >> On Monday, October 22, 2012 at 1:04 AM, Domenic Denicola wrote: >> >> Thanks for your help Rick! I've corrected a few, but wasn't sure about >> some others. Let me know if I'm missing something in the following: >> >> From: Rick Waldron [mailto:[email protected]] >> Sent: Sunday, October 21, 2012 17:07 >> >> nit: The comment itself says "// error! used a `let` before >> declaration.", might be nice to highlight that the error will occur until >> the let is assigned, ie. I can initialize it, but reads will throw until >> it's assigned. >> >> >> If I'm understanding you correctly, you're saying that this should throw? >> >> let x; >> assert(x === undefined); // error! Use of `x` before it is assigned. >> >> yes, any read access will throw before assignment. >> > > We are planning to revisit this once we get some performance measurements > of the cost of the current semantics. But Rick's position contradicts my > understanding of what the current semantics is. My understanding is the > same as Domenic's original: the let declaration initializes x (in this case > to undefined), so the following use is outside the temporal dead zone and > succeeds. > My response was based on a re-reviewing the notes from Sept 20th. I'll accept that I've misunderstood the semantics... Apologies to Domenic for any confusion on this point. Rick > > >> >> I was under the impression the temporal dead zone was about >> use-before-definition, not use-before-assignment. >> >> > Yes. > > >> There is no deadzone in the former, it's use-before-assignment >> > > That is not my understanding. > >> >> >> (For const they are the same, since the "Static Semantics: Early Errors" >> note on page 125 of the spec gives a Syntax Error if the Initialiser is >> omitted from the LexicalBinding.) That is: >> >> "A let and const declarations define variables that are scoped to the >> running execution context’s LexicalEnvironment. The variables are created >> when their containing Lexical Environment is instantiated but may not be >> accessed in any way until the variable’s LexicalBinding is evaluated. A >> variable defined by a LexicalBinding with an Initialiser is assigned the >> value of its Initialiser’s AssignmentExpression when the LexicalBinding is >> evaluated, not when the variable is created. If a LexicalBinding in a let >> declaration does not have an an Initialiser the variable is assigned the >> value undefined when the LexicalBinding is evaluated." >> >> This implies to me that the first line above evaluates the >> LexicalBinding, assigning the variable the value undefined; since the >> LexicalBinding is evaluated, the "may not be accessed" clause no longer >> applies, and no error should occur. >> >> >> I'm not sure the full temporal deadzone semantics are even in a draft yet >> (like lots of things) >> >> >> >> Not sure of the number, but there is a slide titled "Block Scoping" with >> this: >> >> >> if (Math.random() > 0.5) { >> function go() { >> console.log("gone!"); >> } >> ... >> } >> assert(typeof go === "undefined"); >> >> >> I'm not sure I get what this one is trying to illustrate, because "go" >> will always be initialized, regardless of the condition >> >> >> I believe this is not true. The current semantics for block-scoped >> functions bind them to the block, not to the surrounding function. (That >> is, a FunctionDeclaration creates an entry into LexicallyDeclaredNames, not >> into VarDeclaredNames.) >> >> Even in ES5, this behavior is unspecified: see the "NOTE" under the >> "Semantics" heading under section 12 of ES5.1, where it notes that even >> though Statement does not include FunctionDeclaration, implementations >> often allow it, with "significant and irreconcilable variations." (So, I >> don't think "go" will always be initialized in all browsers. For example, >> in IE10 strict mode the above code is a SyntaxError.) It also says that >> "Future editions of ECMAScript may define alternative portable means for >> declaring functions in a Statement context." >> >> And indeed, in ES6 the Declaration grammar production is introduced as a >> sibling to Statement under Block. It includes LexicalDeclaration and >> FunctionDeclaration; VariableStatements are left under Statement. And the >> Block Declaration Instantiation algorithm (10.5.4) includes both >> LexicalDeclarations and FunctionDeclarations, i.e. FunctionDeclarations are >> added to the block's Declarative Environment Record instead of to the >> environment record of the containing function. >> >> new Set(...document.body.children); >> >> >> is a Syntax Error, use: >> >> >> new Set([ ...document.body.children ]); >> >> >> Same for: >> new Set(...array) >> Math.max(...array); >> Math.max(0, ...array, 5, ...array2); >> new Date(...dateFields); >> array.push(...array2); >> >> >> I don't think any of these is a syntax error, since spread works for >> function calls/constructs too. See >> http://tc39wiki.calculist.org/es6/spread/ or section 11.2.5 of the draft >> spec wherein the expanded runtime semantics for ArgumentListEvaluation are >> given (in particular ArgumentList: ...AssignmentExpression and >> ArgumentList: ArgumentList, ...AssignmentExpression). However, you are >> right that the sets should be constructed that way, since the Set >> constructor accepts an iterable and not varargs. Much appreciated! >> >> Not according to SpiderMonkey, so someone has a bug. >> >> >> Also, I just realized that in rearranging my slides I used spread before >> discussing it -_-. Will need to fix. Maybe "rest and spread" are more >> comfort than cowpath-paving... >> >> Weak Sets aren't specified yet. Might be wise to omit that? >> >> >> Yeah, probably a good place to trim the fat. They are harmonious though, >> right? Since they're necessary for revocable proxies. >> >> They are, but no like I said, no spec yet >> >> >> >> One of WeakMap's best use cases is private data... >> >> >> ... This way any number of methods, both on C's prototype or class-side >> functions, as long as they are defined in the same scope that "priv" is >> bound to, can access the private cache in "priv". This beats leaky plain >> object abstractions for a serious win :) >> >> >> The problem I've always had with this is that using weak maps for objects >> you control is silly, when you could just use symbols. Indeed I illustrate >> the symbol vs. weak map question in my "Symbols Again" slide. Weak maps are >> more correct for objects you don't control though, due to the possibility >> of extension-prevented objects (as I plan to point out when that slide >> comes up). But for the simple private data use case, symbols are great. I >> was really glad Brendan reminded me that the values are also held weakly, >> since otherwise weak maps just reduce to a more-cumbersome, but safer, >> version of symbols. >> >> >> It's not silly when you don't have symbols available. >> >> Another better example is using a DOM node as a key to associate data >> >> >> >> Again, thanks for your help, and see you tomorrow! >> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
