Modules: Name capture

Brendan Eich brendan at
Wed Jun 2 13:21:47 PDT 2010

On Jun 1, 2010, at 5:23 PM, ihab.awad at wrote:

> This is extremely common -- see Python and many other languages.
> Yes, and Python and these other languages pull modules out of a  
> centrally curated PATH of some sort wherein 'foo/bar/baz' has an  
> unambiguous meaning to all other modules "installed" on the  
> "system". We are tasked with creating a module system for a world in  
> which these initial conditions do not apply.

"We are tasked" is a bit much. More important: you don't define the  
novel initial conditions, but I'm guessing you mean the Web, which is  
of course not centrally curated.

If so, then my response is to dispute your premise and not swallow  
whatever conclusion you think follows from it.

It's not clear at all that the Harmony module system has so different  
a set of constraints from those facing NodeJS and other users of  
CommonJS modules-and-not-packages. Client-side programmers do not  
include random modules from uncontrolled domains -- not in production  
pages and web apps. Let's dig into this a bit.

I'm not suggesting that we use the web server's doc-tree (filesystem)  
for implicit linking, only that some embeddings of the language, in  
particular Node, seem to want exactly that. From where Node sits on  
the server side, the nearby parts of filesystem are sufficiently well- 
curated ("centrally" or not). TC39 is trying to take non-browser  
embedding use-cases into account.

To turn to the browser embedding, at least these questions seem to be  
raised by analogy to the server-side situation:

1. Is the URL space used by a web app not curated well (centrally or  
otherwise), and somehow fatally unreliable?

2. Is the lexical binding space, a tree of scopes with no object  
aliasing badness, which simple modules proposes programmers can create  
by writing module declarations in <script type="harmony"> tags,  
inherently not well-curated, unlike the case of the server-side  
filesystem for a Node app?

I contend that the answers are "no" and "no".

Any web app author has to control URLs and provide the needed  
resources, whether they use or  
their own hosted/edge-cached copies of modules.

For in-language module naming (as opposed to URL naming), the simple  
modules proposal lets the author of the web page compose modules in  
lexical scopes (and only lexical scopes), naming modules with consumer- 
chosen identifiers and protecting inner bindings within explicit outer  
modules if needed.

We're not considering mutual suspicion. However, the usual rules for  
production web apps apply: URL provisioning means you don't just  
include some uncontrolled version of a module in a production app.

Therefore if there is a good filesystem/PATH curator -- or set of  
curators cooperating -- in the Node server-side case, then there's a  
good curator or set of curators cooperating in the client-side page or  
web app content and the set of modules loaded by that content.

It's true that a module loaded later in a page, app, or other module  
may use a free name that ends up bound at top level by the module  
loader (and only at top level -- there's no injection possible in the  
middle of a module). But this aside, below the top level lexical  
scope, all naming is under control of whoever curates the module  
source at that level.

The extensibility of the simple modules top-level lexical environment  
under the default module loader is neither a fatal flaw ("unhygienic  
capture") nor an unalloyed good. On the plus side, it avoids any new,  
secondary naming system, package indirection, brittle reverse-DNS  
convention, or explicit-linking configuration language. This is a big  
plus for most programmers.

> At this point, it's not clear where CommonJS is going to end up  
> after navel-gazing over the problem of distributed module  
> management. It is clear that they have not arrived at the current  
> "simple modules" design.

The "require" system is pretty close, but lacking new syntax to help  
static analysis -- or really to support second-class modules properly.  
Simple modules fills this gap by extending syntax.

> _Pace_ the definition of implicit vs. explicit linking, I think the  
> problem deserves some further thought. I'm on the hook to provide a  
> clear restatement of my Solution 2 (which, I repeat, may not solve  
> the problem but will I hope clarify some issues), and I have every  
> intention of delivering. :)

Ok, but this is a discussion list, and discussion can go on and on. In  
TC39, we've been going over first-class module ideas for about 18  
months. Until simple modules were proposed this year, we weren't  
getting anywhere quickly.

TC39 is not going to wait for novel research. The simple modules  
strawman is heading toward prototype implementation and  
harmony:proposals status. So some evolution of it is likely to be in  
the next edition.


More information about the es-discuss mailing list