On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: > On 3 January 2012 07:19, Brendan Eich <bren...@mozilla.com> wrote: >> [Dave has been traveling, hope it's ok for me to jump in. /be] >> >> On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote: >> >>> In other words, I think the main points of your proposal can >>> essentially be rephrased to: >>> >>> 1) Rename "use version 6" to "use module". >>> 2) Allow module declarations in classic mode. >> >> [Replying to (1) and (2) here:] >> >> Not just module declarations -- all new syntax that is not >> backwards-incompatible: destructuring, rest/spread, for/of ,generators, >> comprehensions, generator expresions, quasiliterals, more. > > Yes, but that is a totally independent choice.
There are several independent choices bundled into this new "ES6 doesn't need opt-in" proposal, but the unifying theme is this: new features that pose no backward incompatibility hardship and are contained or expressed by new syntax need only that new syntax as opt-in. > We could do that > regardless of Dave's proposal. And I agree, there probably is no good > reason not to. Maybe we can even get "let" in? Maybe. We tried in 2006-2007 and ran into at least this: https://bugzilla.mozilla.org/show_bug.cgi?id=351515 where 'yield' was used as a parameter name. I dimly recall 'let' in the wild but may be misremembering. Perhaps out of paranoia we made both 'let' and 'yield' require version opt-in. The site that used 'yield' has since been updated to avoid using 'yield'. So we could try again to reserve 'let' unconditionally. Heaven knows I've been yapping about 'let' as the new 'var' long enough to warn most developers away from it! I discussed this on IRC briefly with Oliver, who seemed game. The only issue I see is that nightly builds (WebKit, Chrome, Firefox) don't get enough use to do other than find true positives. It would be good to find such 'let' usage in the wild, of course, but finding nothing won't give us a green light, just lack of a red light. >>> 3) Make every module body start with an implicit "use module". >> >> That's not right: use module; in a pragma turns the enclosing block or body >> into a module {...}, in a macro-like way. Then if the module {...} is >> illegal in the given context (i.e., not nested immediately in another >> module's body), you get the same error you'd get trying to write, e.g., >> >> if (cond) { module { /* stuff */ } } > > Hm, I don't follow. How is this related to point (3)? The body of a > module always is a context where module declarations are allowed. Your (3) seemed to say "use module" was something distinct from (and also implicit in, so a part but not the whole of what is declared by) module declaration syntax. It's not -- as proposed, it's an alternative to explicit anonymous module{...} bracketing syntax that translates the block or body enclosing the pragma to an anonymous module. > Isn't it rather a reply to my item (1) above? No, I wasn't talking about ES6 opt-in, only the meaning of the proposed use module; pragma. >>> 4) Keep the semantics of the top-level scope unaltered, even in >>> presence of a top-level "use module". >> >> No, see above: that turns the verbatim top level into the ... part of module >> {...}. > > OK, I see, but then we effectively have opted out of the global > object, at least as a carrier for the verbatim top-level declarations > of the (current) script, haven't we? No. Dave wrote "Short answer: giving up" and "You can still do it with a custom loader". That is, even in a module (declared at top level either implicitly via the |use module;| pragma or explicitly via module id? {...}), the proposal still keeps the global object on the scope chain. But the proposal does a free variable analysis based on importing the properties of the global at the start of the module's body, and any free variables are early errors. >>> I'm fine with (1) to (3), but (4) seems to be a separate design choice. >> >> With what I wrote above in mind, what do you think now? > > Since I'm no longer clear what change (relative to our, admittedly > vague, recent discussion) Dave is actually proposing wrt the > top-level, I don't know. Maybe there is no (4) at all, which I'd be > fine with, of course. :) No (4) as you wrote it. Semantics do change to throw early errors for free variables (typo'ed globals, e.g.). Semantics of the global object on the scope chain otherwise *do not* change with the default module loader. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
