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

Andreas Rossberg rossberg at
Mon Jan 30 10:11:31 PST 2012

On 30 January 2012 18:16, Allen Wirfs-Brock <allen at> wrote:
> 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.

Yes, and just to be clear, I'm not at all advocating allowing it,
quite the opposite.

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

Sure, but I thought the case in question was

import x from wherever1;
import x from wherever2;

(perhaps only in separate scripts). And my claim was that allowing
this is just as problematic as a duplicate let.

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

OK, thanks for clarifying. Yes, I'm using "shadowing" in the general
sense, i.e. one binding hiding the other. And I think I talked about
"intra-scope shadowing" somewhere, to make the distinction.

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

OK, I see. Then I somewhat misinterpreted what you wrote initially.
But even with that in mind, I'm still slightly confused what exactly
you were suggesting. In particular, did you assume that imports from
one script are visible in later ones?

If not, then what environment do they go in? And why have different
rules for imports and other bindings?

If they are, then you might still have the problem I was describing,
if you want to allow duplicate imports as you suggested (what I call

import x from M1

function f() { return x }
import x from M2
function g() { return x }

Which x does each function see, and why?

On the other hand, I see that in the OP you said "multiple equivalent
imports", presumably ruling out examples like the above if both xs do
not refer to the same thing. Was that the idea?


More information about the es-discuss mailing list