ES6 doesn't need opt-in

Andreas Rossberg rossberg at google.com
Wed Jan 4 04:12:03 PST 2012


On 3 January 2012 21:18, Brendan Eich <brendan at mozilla.com> wrote:
> On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
>
>> On 3 January 2012 07:19, Brendan Eich <brendan at mozilla.com> wrote:
>>> 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.
> [...]
>>>> 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.

Yes, I understand that. My point was that you can reformulate all
that, for (almost) equivalent effect, by saying that "use module" is
_not_ a module definition, but basically the same mode pragma as
before, except that it now is implicit with every module body.

The only difference I can see with this description is its effect on
the semantics of multi-part scripts.

>>>> 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.

Those quotes from Dave's post are exactly the bits I couldn't make
sense of properly. Because even before his proposal, I remember what
you describe being an option we were still considering. Thanks for
clarifying.

/Andreas


More information about the es-discuss mailing list