andy at chubot.org
Sat Jan 30 11:08:16 PST 2010
On Fri, Jan 29, 2010 at 5:13 PM, David Herman <dherman at mozilla.com> wrote:
> We had a good discussion about modules at this week's meeting, and Sam Tobin-Hochstadt and I have worked out a strawman for a simple module system. I've posted a first draft to the wiki:
> There are lots of examples to peruse at:
> which might also be a decent starting point to get a feel for the design.
Thanks for the examples page. I think it would be useful to have
comparable examples for the other 3 modules strawmen too.
> This has a good bit of overlap with -- and is in many ways inspired by -- Ihab and Chris's work, but it has at least one major departure: modules in this proposal are not inherently first class values, although we do provide ways of getting objects that reflect the contents of modules.
So, as Brendan described, they're not first class because you want to
analyze dependencies statically?
I agree that's a really common requirement. I've found that to be a
problematic area of CommonJS modules, but I think it can be resolved
pretty easily. I will write something about this, but basically I
just have a special syntactic restriction on require() statements.
"embeddable" modules are a subset of modules, and are statically
The 3 use cases I see for statically analyzing dependencies are:
1. async/parallel module retrieval over HTTP (need to retrieve modules
before evaluating them)
2. static "linking" (what http://code.google.com/p/gelatin-js/ does,
need to get dependencies without executing the program)
3. parameterized modules / module metaprogramming (need to get
dependencies first for exposing to users)
For comparison, I would point to the fact Python has evolved a crazy
number of module metaprogramming facilities over the years. It isn't
obvious why, but basically any large Python program does something
"weird" with modules in my experience (i.e. involving a Turing
More information about the es-discuss