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

Andreas Rossberg rossberg at
Mon Jan 30 04:15:02 PST 2012

On 28 January 2012 02:08, Allen Wirfs-Brock <allen at> wrote:
> On Jan 27, 2012, at 12:07 AM, Andreas Rossberg wrote:
>> Yes, every binding sees every other binding in the same scope
>> (including itself). It is not clear to me how that can be combined
>> with intra-scope shadowing. Which instance of a name would be visible
>> where in the same scope?
>> There are many programming languages that allow shadowing in the same
>> scope, and quite a few that have recursive scopes. But I don't know
>> any that would have both. I believe it's asking for trouble.
> I played around a bit to see if I could come up with a troublesome example
> of the sort you may be thinking about.  What I came up with is the follow:
> <script>
> module a {
>    import {x:y} from b;
>    module b{
>       export let y = x;  //essentially this is let y=y
>     }
> }
> </script>

Well, there is no shadowing in this example, so this is just an easy
case of a cyclic definition that runs into a temporal dead zone

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 }

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.

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


More information about the es-discuss mailing list