Module system strawpersons

Mike Samuel mikesamuel at
Fri Jan 15 11:20:48 PST 2010

2010/1/15 kkasravi <kkasravi at>:
> Hi Mike, Ihab:
> One factor that would influence eager or lazy fetching is where the
> import keyword may appear within the ecmascript grammar.
> The proposal suggests it could appear anywhere
> an identifier could appear. For example:

I believe it cannot appear where a LeftHandSideExpression is expected
because a function cannot be assigned to.
So no replacing = baz
  (import ...) = baz

> 1)  function find(name) {
>       var name =; // identifier ''
>        ...
>     }
> Replacing with import would yield
> 2) function find(name) {
>      var name = (import 'foo/bar').Baz.find(name);

Provisioning is separate from importing.  The above is looking up Baz
on a function instance which normally would be the same as
   var name = Function.prototype.Baz.find(name)

I think normal usage would look like
     var name = (import ...)(module, instance, parameters).Baz.find(name)

>      ...
>    }
> Replacing with import would yield
> 3) function find(name) {
>      var name = (import 'foo/bar/Baz').find(name);
>      ...
>    }
> I provided 2) and 3) because its not clear where a module definition begins.
> The presumption by naming convention is that can be found within
> a relative resource named ./foo/bar.js on some server. This metadata needs to
> be somehow made available to the javascript runtime. So in some ways
> module's need package info. Let's assume the correct one is 2).
> Looking at 2), current javascript behavior is always lazy fetching because the above function find

fetching can be eager, but evaluation happens whenever the ImportExpr
is reached, possibly not at all.

> may not be called immediately or not at all.  The javascript runtime would not complain about
> identifiers that are not immediately accessed or not accessed at all.
> Doing eager fetching means that we would need to fetch all imports prior to eval.
> Impacts are:
> 1. We fetch more than necessary and immediately. User perception is the new js runtime is much slower.

Eager fetching can be done, or can be delayed, or multiple module
definitions could be fetched in the same transaction.  The degree of
eagerness is up to the interpreter.

> 2. We forces all import expressions to be statically defined.
> Summary:
> If import can appear in place of an identifier, there is no choice but to
> do lazy fetching. Lazy fetching without CPS (continuation passing style)
> support means you could not do (import foo/bar').Baz.find(name);
> Kam
> On Jan 14, 2010, at 2:29 PM, Mike Samuel wrote:
>> Ok, so let me try to make sure I understand the special form in
>> strawman:modules_emaker_style, by defining a mini-strawman and
>> knocking it down.
>> Consider a special form
>>   (f, definer) = defineDelayedFunction();
>> where f is a function that will block on first call until definer has
>> been called with an arguments array and a function body upon which
>> point it will behave as if it were defined via new Function(...) with
>> those arguments and function body.  definer raises an Error on second
>> and subsequent calls.
>> defineDelayedFunction could be used with an async channel like
>> XMLHttpRequest to define a module system, but all module definitions
>> would happen at execute time, so it cannot be used to define a module
>> system that resolves definitions prior to body evaluation.
>> In modules_emaker_style, imports are statically determinable, so the
>> set of dependencies is fully satisfied before the Program is
>> evaluated, and this can be done recursively to make full use of
>> sockets.  A browser could optimistically find import definitions and
>> start downloading before the full script body is loaded.
>> defineDelayedFunction would impose lazy fetching, but
>> modules_emaker_style allows eager fetching.
>> 2010/1/14  <ihab.awad at>:
>>> 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
>>> harder.
>>>> "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
>>> --
>>> Ihab A.B. Awad, Palo Alto, CA

More information about the es-discuss mailing list