On Jan 30, 2012, at 4:15 AM, Andreas Rossberg wrote:
> On 28 January 2012 02:08, Allen Wirfs-Brock <[email protected]> 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.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
