Global lexical tier
Brendan Eich
brendan at mozilla.org
Thu Sep 3 18:57:24 UTC 2015
Andreas Rossberg wrote:
> On 3 September 2015 at 03:50, Brendan Eich <brendan at mozilla.org
> <mailto:brendan at mozilla.org>> wrote:
>
> I don't remember you overcoming the counterarguments about async
> scripts and event handlers in async-generated/written markup
> twisting the nested scopes unexpectedly.
>
>
> The only cases where the scope order would make an observable
> difference are ones that produce conflicts right now. So you'd only
> allow a few more programs -- somewhat ill-behaved (non-deterministic)
> ones, but no more ill-behaved than those that you can write with `var`
> today (or could with `let` if it was a property on the global object!
> -- non-deterministic shadowing is still a less drastic effect than
> non-deterministic overwriting).
The problem is the cognitive model and load. Nothing helps
non-deterministic loading of scripts with global effects, but making
every. last. script! nest a fresh lexical scope means "now you have two
problems".
People should keep eyes on the prize. You want a lexical-only top-level,
use modules. Real-world JS hackers already are, server- and client-side.
Let script be what it is, a means of global object coordination (object
detection, primarily) as well as global code loading. It's not going
away any time soon, but it need not be over-complicated to serve the
"lexical all the way up" use-case poorly compared to modules.
> I thought we resolved this (non-simple parameter list in function
> makes "use strict"; directive prologue an early error). What's left?
>
>
>
> It's unrelated. The grammar is LL(2) regarding sloppy `let`, so the
> scanner needs the ability to do one extra token of look-ahead to let
> the recursive-decent parser deal with it (unless, perhaps, you
> completely transform all the grammar; not sure if that would be
> possible). Enabling that creates a slight performance bottleneck.
> Plus, look-ahead in a JS scanner is very brittle, given the lexical
> ambiguities and context dependencies around regexps.
I'm interested in what other implementors have to say.
/be
More information about the es-discuss
mailing list