simpler, sweeter syntax for modules
claus.reinke at talk21.com
Fri Mar 23 09:02:43 PDT 2012
> 2. Also we are not losing static binding by having the names injected
> by static syntactic forms depend on control flow dynamics.
When statically checkable constraints meet dynamic load/eval,
it isn't necessary to have a strict static/dynamic split. It would be
possible to adopt a multi-staged design, where there are multipe
dynamic phases, each with its own preceding static phase: no
code runs without static checks, no static properties are affected
by dynamic code in the same stage.
I am trying to understand whether ES6 aims for such a multi-staged
design, or whether entering a dynamic phase forever precludes
the use of static constructs from the modules spec.
Part of the spec suggest multiple stages, eg. harmony:modules
Reflective evaluation, via eval or the module loading API
starts a new compilation and linking phase for the dynamically
Other parts suggest a single stage, eg harmony:modules
limits ImportDeclaration to Program and ModuleBody
top-levels, ruling it out in loader callbacks. Right?
Similarly, reflecting Modules as Objects brings us from
static into dynamic but -presumably- import statements
work with reflected Modules. Or don't they?
More information about the es-discuss