On 3 September 2015 at 03:50, Brendan Eich <bren...@mozilla.org> wrote:
> Andreas Rossberg wrote: > >> On 3 September 2015 at 01:58, Brendan Eich <bren...@mozilla.org <mailto: >> bren...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
