Request for feedback on a talk on I'm giving on ES6

Mark S. Miller erights at google.com
Mon Oct 22 09:43:18 PDT 2012


On Mon, Oct 22, 2012 at 5:27 AM, Rick Waldron <waldron.rick at gmail.com>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:waldron.rick at gmail.com]
> 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.


>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121022/377c7011/attachment-0001.html>


More information about the es-discuss mailing list