Module system strawpersons

Kam Kasravi kamkasravi at yahoo.com
Sat Jan 16 13:13:01 PST 2010


Within that body of literature there is one called Higher Order Functors which describes in this context modules being initialized with modules all of them parameritized. It looks like this is possible and powerful. 

Kam

On Jan 16, 2010, at 11:47 AM, Andy Chu <andy at chubot.org> wrote:

On Thu, Jan 14, 2010 at 1:58 PM,  <ihab.awad at gmail.com> wrote:
Hi Mike,

On Thu, Jan 14, 2010 at 1:29 PM, Mike Samuel <mikesamuel at gmail.com> 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
useful.

Most of these papers are about this distinction (especially the
Newspeak papers, and the Scala one):
http://lambda-the-ultimate.org/node/3735

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:

http://code.google.com/p/gelatin-js/  (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.

thanks,
Andy
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list