domenic at domenicdenicola.com (2014-10-15T18:58:24.143Z)
> 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
```js
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...
> 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.