Hi Andy, > So, as Brendan described, they're not first class because you want to > analyze dependencies statically?
A number of reasons: - the dependency graph is statically computable - first-class modules duplicate existing expressiveness of functions and objects - exposing more information to the compiler increases optimization opportunities, particularly parallelization - modules encapsulate bindings The consequence of the latter point is that in our strawman, modules are a lexical scoping mechanism-- they let programmers divide up scoped regions into manageable pieces and still use lexical (ie, static) scope to refer between one another. This is not to say that you *can't* have a first-class module system that still manages static information like bindings, but it's hard to keep it simple, which was one of our goals. More abstractly, I'd say that 2nd-class modules embody the notion of modules as units of deployment and units of definition. These are both commonly static concerns. But when they need to be determined dynamically, you pull out the power tools like `eval' or `loadModule'. Dave _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
