Global lexical tier

[Brendan Eich]

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