Module system strawpersons

Kris Kowal kris.kowal at
Sun Jan 17 01:07:06 PST 2010

On Thu, Jan 14, 2010 at 1:06 PM,  <ihab.awad at> wrote:
> 1.
>      Module proposal, by Kris, focusing on management of primordials.

I've revised this first proposal to support all of the "import id
[from package] [with scope]" forms necessary for Ihab's second and
third proposals, and restricted the "id" expressions to Strings, while
leaving the "package" expression open to any JSON.  Assuming that
package bindings are managed externally (as they are presently
proposed to be at CommonJS), this could be further constrained to
Strings; I do not have an opinion on the matter.  In any case, I'm
attempting to line things up better so that proposal 2 can stack on
proposal 1, as Andy suggested.

Also, with regard to externally managing module instantiation, these
primordials could support several possible systems.  The first is to
construct sandboxes with primed module memos with manually
instantiated modules.  The second is to interpose a loader that
provides alternate module functions which in turn instantiate the
desired modules on demand.  The third is to not use "require" at all,
and simply to presume that certain free variables have been provided
with instances of the modules a module depends upon.  Both have
advantages and disadvantages and both can be built on the recommended

Kris Kowal

More information about the es-discuss mailing list