On Jun 1, 2010, at 5:23 PM, [email protected] 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 http://code.google.com/apis/ajaxlibs/ 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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
