Minimal Module System Proposal

[Brandon Benvie]

I am hesitant to call this "maximally minimal" because the driving force
behind coming up with this varies significantly from what drove maximally
minimal classes. The driving force for this is the realization that the
module system is perceived as being not close enough to being finished for
ES6, yet is agreed to probably be the most important feature that could end
up in ES6.

The goal here is not to claim that all is lost with the module system in
full, because I do think that's not a certainty yet. I do think it is a
likely enough outcome that there should be a fallback to capture the most
important parts and make sure that they do make it to ES6. I think these
parts can be limited to a subset of the module system that is agreed upon
and is the most important parts of it, without compromising any other the
other "at risk" parts for the future.

The premise of my concept for a minimal foundation system rests on the
following assumptions:
* The import syntax that parallels with destructuring is favored and mostly
agreed upon.
* The _most_ important part of the module system needed for ES6 is the
ability to import internal modules ('@iter'...).
* The points of contention about the current module system are mostly about
exporting user modules (resolving, etc.).
* Internal modules have no need for resolution/export specification, only
import. Nor do they need any specification for special binding, since they
will be immutable.

The proposal extends simply enough from those assumptions: Pieces of the
module system specification that are needed to support loading internal
modules should be prioritized over all else, and the expectation should be
that this will definitely work in ES6:

    import { Symbol } from '@symbol';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130207/88df5f32/attachment.html>