Global lexical tier
Brendan Eich
brendan at mozilla.org
Tue Sep 1 02:11:01 UTC 2015
We are in rapid-release hell/heaven.
This means errata can be issued, and engines can implement the better
resolution for those errata, compared to what the last major-version _de
jure_ spec mandated.
Why not?
/be
Adam Klein wrote:
> Note that this behavior in v8/Chrome is only about sloppy mode. In
> strict mode, v8 implements the ES6 spec (and we'll likely have support
> for lexical declarations in sloppy mode soon).
>
> Though I personally agree that the top-level lexical scoping in ES6
> seems unfortunate.
>
> On Mon, Aug 31, 2015 at 9:53 AM, Matthew Robb <matthewwrobb at gmail.com
> <mailto:matthewwrobb at gmail.com>> wrote:
>
> Personally I am a fan of Chrome's CURRENT solution:
> ```
> Uncaught SyntaxError: Block-scoped declarations (let, const,
> function, class) not yet supported outside strict mode
> ```
>
>
> - Matthew Robb
>
> On Mon, Aug 31, 2015 at 12:08 PM, Jason Orendorff
> <jason.orendorff at gmail.com <mailto:jason.orendorff at gmail.com>> wrote:
>
> Hi everyone. Can we talk about the global lexical tier?
>
> This was a mistake, a real blunder. We all should have known
> better.
> An extensible intermediate scope implies dynamic scoping. The
> referent
> of an identifier can change only once, but it can change. It's
> like an
> implicit `with` block around *all code*.
>
> This pattern for declaring variable in multiple scripts won't work
> with let/const:
>
> var MyES3Module = MyES3Module || {};
>
> There's no workaround except "keep using var".
>
> It's now possible to get a binding permanently wedged, which
> is bad for a REPL:
>
> js> let z = Maht.PI; // oops, typo
> ReferenceError: Maht is not defined
> js> z
> ReferenceError: binding is not initialized: "z"
> js> z = 1;
> ReferenceError: binding is not initialized: "z"
> js> delete z;
> false
> js> let z = 1;
> SyntaxError: redeclaration of variable: "z"
>
> For a single name to have two global bindings, both mutable,
> is astonishing.
>
> All of this was unnecessary. What's the benefit to users? We ran
> roughshod over existing practice, invariants, and expectations in
> order to obtain a kind of self-consistency for `let` that
> users don't
> expect or even care about.
>
> We should have just made toplevel let/const/class create global
> properties, like var. This is how it was proposed originally
> and how
> Babel implements it today. For SpiderMonkey, switching to the
> worse,
> less user-friendly way without regressing performance is
> time-consuming.
>
> We knew all this. We didn't evaluate it correctly. What we
> particularly missed is that we already had modules as the way
> forward
> to a nice toplevel lexical tier, and weird half measures for
> scripts
> were pointless.
>
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list