Module system strawpersons

ihab.awad at ihab.awad at
Thu Jan 14 13:58:42 PST 2010

Hi Mike,

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

> I don't see the word module anywhere in the packages proposal besides footnotes.
> What is the relationship between packages and modules.

The packages proposal was written with module proposal (1) in mind,
but is compatible in the broad sense with either. It does say in the
beginning that it "... is intended to satisfy the Uniform location and
retrieval goal of modules_emaker_style". There are more details under
"Use in import" (where I just updated the syntax a little bit).

>> 2.
>>      Module proposal, by Ihab, focusing on EMaker-style invocation semantics.
> "First class objects. To the extent possible, module system components
> must be represented as first-class ECMAScript objects."
> Does object exclude primitives such as strings, or is the goal to
> exclude abstractions like LexicalScopes and References?

The point is that module system components are made to appear, to the
extent possible, as first-class objects rather than unmentionable
"static" magic. E.g., contrast Java where, if Foo is a class, the
expression "Foo" by itself is not an object; generic class parameters
are not objects; etc. -- which makes higher-order programming somewhat

> "import" is added to the reserved keyword list?

It should be reserved now, and is for sure reserved according to this proposal.

> "return {
>  getX: function() { return x; },
>  getY: function() { return y; },"
> indentation

Fixed, tx.

> "In the module’s code, this is initialized to a new object that is
> instanceof the module function"
> Does this mean that access to a module instance conveys authority to
> create new module instances?

Yes. Just like any other ES function where it's return value is
instanceof that function.

> "An import expression evaluates immediately to a module function
> despite the fact that the specified module may have been fetched by
> asynchronous means (e.g., nonblocking network operations). This is
> done by taking advantage of the fact that import is a special form."
> Does this require "import" to be a special form instead of a
> desugaring?  Or can the special form be boiled down to a function
> which when called, delays until another function is invoked,
> presumably with a valid FunctionExpr string as its sole argument?

Would that require a continuation-passing transform of the code after
the desugared "import"? If so, that may not be semantics preserving.


Ihab A.B. Awad, Palo Alto, CA

More information about the es-discuss mailing list