Modules: Curly Free
brendan at mozilla.com
Sun Apr 21 09:58:47 PDT 2013
Sorry, let me say a bit more.
You identified the entry-point idea. Good so far.
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.
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.
Mark Miller tried to get generative (callable) modules working here:
But Mark just wrote last week: "However, I don't actually have a
coherent end-to-end proposal for making this
doesn't work), and it is clear that I could not agreement on one at the
present time even if I had one."
Anonymous export is distinct from callable modules. Some uses of
anonymous export make the entry-point an object other than a function.
Brendan Eich wrote:
> Claus Reinke wrote:
>>> 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,
>> that of scripts-vs-modules (executable code vs declaration container).
>> Would it be possible to combine the two issues, with a common
>> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss