Module system strawpersons

Andy Chu andy at
Sat Jan 16 11:47:11 PST 2010

On Thu, Jan 14, 2010 at 1:58 PM,  <ihab.awad at> wrote:
> Hi Mike,
> On Thu, Jan 14, 2010 at 1:29 PM, Mike Samuel <mikesamuel at> wrote:
>> Are these proposals mutually exclusive or complementary.
>> If (1) and (2) are exclusive, is there a place to collect use cases
>> for a module-off?
> For my part, I think (1) and (2) are counterproposals, but there may
> exist a bunch of cross-pollination. For example, I will probably end
> up stealing Kris's "import with" syntax sometime.

Are they really?  The primitive proposal says: "This proposal
specifies support for both “loading” dependencies as module factory
functions (Makers) ..."

I can see how the Makers will work, but I think to convince ourselves,
it would be good to provide example #4 of implementing Makers on top
of Context()  (proposal 2 on top of proposal 1).  I like the approach
of providing a primitive Context() and then being able to implement
Makers-style modules in those semantics (i.e. with pure JS code).

For makers, what you're essentially proposing is "parameterized
modules", no?  The modules are parameterized by their dependencies.
That is something I strongly support, but is unusual compared say
Python or Ruby's module systems.  In those systems, dependencies are
essentially hard-coded.  I think making this clear in the proposals is

Most of these papers are about this distinction (especially the
Newspeak papers, and the Scala one):

The way I think of it is that there are "bound" and "unbound" modules
-- you bind the dependencies ("requires") of the Module by calling its
module function with concrete dependencies.

I've been working on some code which does allows this extra degree of
flexibility for CommonJS modules:  (needs docs, coming shortly)

Basically you say require('file') in the source code.  And then at
build time, bind 2 different implementations to that "requirement",
depending on where you want to deploy.  You can think of this as
"module metaprogramming at build time", whereas the makers proposal is
module metaprogramming at runtime, in JavaScript.

In one of the Newspeak papers he talks about not conflating "module
definition" and "module configuration" (e.g. which Python/Ruby/Perl
do).  I agree with this -- there is one mechanism to define modules,
and then you can configure the modules at build time or runtime.

JavaScript especially needs this feature because there are so many
different execution environments, and no standard library (yet).

So I really like the general ideas of these 2 proposals, but some of
the details are unclear.  I think relating things to CommonJS modules
is good because they are already implemented quite widely.


More information about the es-discuss mailing list