Global lexical tier

[Andreas Rossberg]

On 3 September 2015 at 03:50, Brendan Eich <brendan at mozilla.org> wrote:

> Andreas Rossberg wrote:
>
>> On 3 September 2015 at 01:58, Brendan Eich <brendan at mozilla.org <mailto:
>> brendan at mozilla.org>> wrote:
>>
>>     I was there, I just re-read and re-remembered. I do not agree with
>>     Allen that some tiny needle was uniquely threaded. Rather, an
>>     aesthetic preference for the new ES6 binding forms to have a
>>     lexical contour of their own when used at top level prevailed.
>>     This leads to problems, not all of which were known at the time --
>>     but some problems were noted.
>>
>>     The REPL problem, where let z=z; makes a poison pill, could be
>>     coped with by ad-hoc REPL deviations from the spec -- at some
>>     cost. Let's set it aside.
>>
>>     The one-time change to a reference, from global object to lexical
>>     shadowing binding, is a serious flaw. Yes, it could happen due to
>>     explicit scope nesting, but the global scope is apparently
>>     uniform. There's no explicit delimiter.
>>
>>
>> I still maintain that a tower-of-nested-scopes model would have been
>> cleaner AND would have avoided both the shadowing issue and the REPL
>> restriction. A mutable scope that gets extended under your feet is
>> terrible, lexical or not.
>>
>
> 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).

So from my perspective, there is nothing to overcome, at least not relative
to other alternatives. :)  In particular, this one:

Or unless one makes toplevel binding semantics completely different (and
>> insane), which I also hope nobody wants (though I'm not so sure).
>>
>
> Something has to give. This seems least bad.


I disagree. In particular, since this solution is even less well-behaved,
see above.


The main thing holding back sloppy let in V8 right now is the parsing
>> nonsense and extra look-ahead required, which turns out to be a major pain
>> for us (and FWIW, slows down the V8 parser by a couple of percent with
>> little hope for recovery :( ).
>>
>
> 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.

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150903/c2444e5e/attachment.html>