The global object should not be the "global scope instance object"

Allen Wirfs-Brock allen at
Mon Jan 30 09:16:14 PST 2012

On Jan 30, 2012, at 4:15 AM, Andreas Rossberg wrote:

> On 28 January 2012 02:08, Allen Wirfs-Brock <allen at> wrote:
>> On Jan 27, 2012, at 12:07 AM, Andreas Rossberg wrote:
> ...
> I was referring to something else in the above quote. For ES, the
> conflict between recursive scoping and shadowing is perhaps best
> demonstrated by this simple example:
> let x = 1
> let x = 2  // assume this is allowed
> function f() { return x }
> f()

Assuming this is a single Program or StatementList, the above is current defined as being a static error.  The above would require changing decisions that have already been made so I don't see why we should be considering such cases unless we run into an issue that forces us to reconsider that decision.

> The function will get hoisted over both bindings for x. In the end,
> which one is it referring to?
> And as I said earlier, by allowing import shadowing, you could encode
> this, even if shadowing was disallowed for let itself.

I don't think so.  Imports are treated as local lexical bindings, just like let and const so:

import {x} from wherever;
let x = 2;

is just as illegal as:

let x=1;
let x=2;

I think part of our terminology mismatch is that you are willing to consider the possibility of multiple declarations for the same name in a StatementList, for example:

let x=1;
let x=2;

and you call this shadowing.  I think we have already rejected this semantics and I only use "shadowing" in the context of nested scopes such as:

let x=1;
{ let x=2}

>>> <script>
>>> module _fn1_ {export let x = e}
>>> import {x} from _fn1_
>>> </script>
>>> <script>
>>> module _fn2_ {export let x = e}
>>> import {x} from _fn2_
>>> </script>
>>> And you have two different instances of x, one shadowing the other.
>> or the 2nd import is illegal because it is a duplicate definition in the
>> common top-level scope,
>> or the two scripts don't share a common top-level lexical scope and hence
>> the two imported x bindings are distinct but neither shadow the other
> Well, yes, but that wasn't the point, was it? In your OP proposing
> STL, you made an exception for allowing imports to shadow each other.
> With the example, I was demonstrating that that is almost equivalent
> to allowing shadowing in general.

No, I suggesting allowing duplicate identical imports in separate Programs while I would disallow (for STL) multiple lets for the same identifier.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list