Modules: compile time linking (was Re: Modules feedback, proposal)

Claus Reinke claus.reinke at
Fri Apr 6 02:04:05 PDT 2012

I just noticed that James' original email had two more items:

>>>* The 'Math' module is evaluated before Foo is evaluated.
>>>* Only the properties on Math that are available at the time of Foo's 
>>>execution are bound to local variables via the "import *".

which puts it in line with the first option I mentioned, contrary
to my final paragraph. Also, he seems concerned mostly with
static modules, not dynamic ones.


>>> So, assuming Math has no dependencies (just to make this shorter), the
>>> sequence of events:
>>> * Load Foo, convert to AST, find "from" usage.
>>> * Load Math
>>> * Compile Math
>>> * Evaluate Math
>>> * Inspect Math's exported module value for properties
>>> * Modify the compiled structure for Foo to convert "import *" to have
>>> local variables for all of Math's properties that are known, only at
>>> this time (no funny dynamic 'with' stuff)
>>> * Evaluate Foo
>> This is certainly the events I expect: is there an alternative? I suppose
>> the module syntax could support moving Evaluate Math to just before
>> Evaluate Foo. (a la a compiled language) The Math-level operations that
>> created Math properties would not be known to Foo. That would be a major
>> surprise to devs I think.
> Several. The interaction of dynamic modules and static program
> properties makes for an interesting design space - conveniences
> you want to allow in one place quickly have unwanted consequences
> in other places (for instance, I'm not convinced that James' scheme
> does not permit to emulate 'with'). A few alternatives:
> - you could try to determine Math's exported properties before
>    compiling the importer
> - you could try to split Math into an interface (that statically fixes the 
> exported properties) and an implementation (that allows
>    dynamic instantiation of its interface); as long as the export 
> interface remains invariant, dynamic changes to Math do not harm the 
> dynamic importers static binding structure, even in
>    the presence of 'import *'
> - you could allow Math's properties to be determined at load
>    time (runtime of the importer), but drop the convenience of
>    'import *'; that allows Math's exported properties to change
>    dynamically without affecting the static binding structure
>    in the importer - essentially inlining a module interface in
>    the import constructs (also, 'import *' is considered by many as bad 
> documentation, even in static module languages)
> - ...
> Note that none of the three I listed quite matches the one given by James. 
> My feeling is that ES6 modules aim for the first of
> the alternatives I listed, with a dynamic fallback that does
> not permit 'import *'. I agree about not permitting 'import *'
> in combination with dynamically changing export lists, but
> I would like to be able to use import destructuring with an
> explicit import list even for this case.
> Claus
> _______________________________________________
> es-discuss mailing list
> es-discuss at


More information about the es-discuss mailing list