simpler, sweeter syntax for modules

Claus Reinke claus.reinke at
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 
    evaluated code.

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 mailing list