A compiler can convert references like these

import {myGlobalFunction, MyPolyfilledConstructor} from "@global";

myGlobalFunction(42);

into

global.myGlobalFunction(42);

And the global scope can be window for a browser.

This code has the exact same semantics as if the global scope was allowed
fully into the module.

The only difference is that the developer is being asked to explicitly list
the bindings that should be allowed filter through.

B.


On Wed, Oct 8, 2014 at 2:49 PM, Brian Di Palma <offler at gmail.com> wrote:
>> On Wed, Oct 8, 2014 at 1:52 PM, Andreas Rossberg <rossberg at google.com> wrote:
>>
>> No, that's not correct. They have to perform a full syntax check. That
>> does not imply binding analysis, though, which is usually regarded
>> part of the static semantics of a language, not its (context-free)
>> syntax. (More by accident than by design, JavaScript so far didn't
>> have much of a static semantics -- at least none that would rule out
>> many programs, i.e., induce compile-time errors. Hence engines could
>> get away with lazy compilation so well.)
>
> Right, I see.
>
>> Yes, see the earlier posts by Dave an myself. Didn't happen, though.
>
> This seems an implementation detail of the engine, especially as you
> can't introduce checking to scripts.
>
>> You can indeed parallelise parsing and checking of separate modules,
>> but each individual task would still take longer, so there would still
>> have been a potential overall cost.
>
> There will be a cost but it didn't sound like that was the reason why
> checking was taken off the table. I thought it was more around the need
> to still have access to the global scope in backward compatible code.
>
>> Yes, but unfortunately, you cannot distinguish between the two in
>> JavaScript -- globals, monkey patching, and all that lovely stuff.
>
> The way the global import would work would be more akin to a filter.
>
> When a developer uses the global import they are saying "allow these identifiers
> from the global state to be available in my module".
>
> In the current approach there is a filter, it's just implicit and open
> to all identifiers.
> This change is about making it explicit and configurable.
>
> When a developer writes
>
> import {myGlobalFunction, MyPolyfilledConstructor} from "@global";
>
> she creates a binding to these identifiers from the systems global scope.
>
> Unlike other bindings they will not be checked for existence.
> All the system will do is provide them if they exist, change them if they
> are changed and introduce them to the module scope if they are created
> at a later
> stage.
>
> The developer has no guarantees about these specific bindings.
> Just like any other global binding, it's purely a declaration mechanism.
> You are free to access global state, just declare it up front.
>
> Therefore even monkey patched/poly filled code will be allowed through.
> Any binding what so ever can be allowed through.
>
> I would hope that in future that new constructors will be added to standard
> modules though...
>
> B.

A compiler can convert references like these

```js
import {myGlobalFunction, MyPolyfilledConstructor} from "@global";

myGlobalFunction(42);
```

into

```js
global.myGlobalFunction(42);
```

And the global scope can be window for a browser.

This code has the exact same semantics as if the global scope was allowed
fully into the module.

The only difference is that the developer is being asked to explicitly list
the bindings that should be allowed filter through.