[e-lang] Module loading discussion

[ihab.awad at gmail.com]

Hi Jonathan,

On Thu, Dec 3, 2009 at 5:50 AM, Jonathan Rees <jar at mumble.net> wrote:
> I wrote a reply and put it here:
> http://odontomachus.wordpress.com/2009/12/03/javascript-modules/

Thanks for the remarks.

> I'm not on google-caja-discuss so did not attempt to cc: there. (maybe I
> should be.)

Please let me know if I should add you. :)

     *   *   *   *   *

It turns out that we _do_ some early-phase stuff. It's so well hidden,
however, that you would not see it if you didn't know where to look.
One outcome of your remarks could be that we should make it clearer.

The Caja 'load()' (and CommonJS 'require()', fwiw, works similarly)
follows a convention that 'load()', when invoked where 'load' is a
free variable of the module, can only be called with a string literal
as its argument. Our compiler enforces this, effectively making 'load'
a built-in operator.

To dynamically load, we provide 'load.async()' which returns a promise
for the result.

We take advantage of this in our compiler. As you might know, we
compile each module to an object literal of the form:

  {
    instantiate: function(___, IMPORTS___) { ... },
    includedModules: [ 'module1', 'module2', ... ]
  }

where 'includedModules' shows precisely the static dependencies. A
build or deployment system can then take advantage of this
information. Hopefully, we can work through ECMA TC39 to find a way to
bake this information into the JS syntax in a more easily parseable
manner than just looking for a function call with a string literal.

At the moment, on CommonJS, we are trying to spec out "packaging"
where a group of modules (module = individual JS file) form a package
(e.g. as a ZIP file). The idea is to embed metadata in the package
headers that can securely specify where to fetch a required package
and how to verify its contents.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA