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 <[email protected]> wrote: On Thu, Jan 14, 2010 at 1:58 PM, <[email protected]> wrote: Hi Mike, On Thu, Jan 14, 2010 at 1:29 PM, Mike Samuel <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
