Modules: Curly Free

Claus Reinke claus.reinke at
Sun Apr 21 13:43:25 PDT 2013

> But then you went too far and made that entry-point, which with 
> anonymous export is often (but not always) a function, with the body 
> of the module, its top-level code.

I suggested that modules be callable, executing the module body and
returning what would be the anonymous export. I did not suggest that 
the exports themselves need to be callable.
> A module is not a function. It is not generatjve when nested. The 
> current proposal doesn't support nesting, but earlier versions did, and 
> that was critical to the second-class nature of modules when declared.

Yes, one would want caching of execution&returns, to keep modules
singletons (and to keep anonymous export consistent across imports).

The real fly in the ointment is that JS does not separate side-effects
from pure code, so it isn't possible to separate declarations and
code execution entirely (the module code needs to be executed,
once, somewhere between first import and first use). This currently
happens implicitly, and is part of the problem that brought down
the earlier lexical modules.

Still, making modules (singleton-)callable would provide a simple 
syntac for accessing anonymous exports, without interfering with
the existing import/export features. Existing AMD and node 
(single-export) modules could be translated to this, where a 
full translation to statically checked, named export/import is
not wanted.

>>>> Anonymous export is simply about allowing library authors to 
>>>> indicate a module's main entry point. Semantically, we're talking 
>>>> about the difference between a string and a symbol; syntactically, 
>>>> we're talking about one production. It's all cleanly layered on top 
>>>> of the rest of the system. Let's keep some perspective.
>>> If you put it like this ("entry point"), it recalls another issue, 
>>> namely
>>> that of scripts-vs-modules (executable code vs declaration container).
>>> Would it be possible to combine the two issues, with a common
>>> solution?
>>> Something like: modules are importable and callable, importing a 
>>> module gives access to its (named) declarations but doesn't run any 
>>> (non-declaration) code, calling a module gives access to a single 
>>> anonymous export (the return value) while also running any 
>>> non-declaration code in the module.
>>> Claus
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list