Global lexical tier
Andreas Rossberg
rossberg at google.com
Thu Sep 3 14:50:52 UTC 2015
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>
More information about the es-discuss
mailing list