Module system strawpersons

Kam Kasravi kamkasravi at
Fri Jan 15 14:58:15 PST 2010

comments below...

From: Mike Samuel <mikesamuel at>
To: Kam Kasravi <kamkasravi at>
Cc: kkasravi <kkasravi at>; es-discuss <es-discuss at>
Sent: Fri, January 15, 2010 1:45:52 PM
Subject: Re: Module system strawpersons

2010/1/15 Kam Kasravi <kamkasravi at>:
> Ihab, Mike - Thanks for the comments.
> Yes, my examples confused definition with declaration, thanks for the
> corrections.
> I think I still have some unanswered questions which I'll try and clarify
> as:
> 1. I'm still not clear what the module identifier represents.
>     Something like 'a/b/c' could be a URI or associated with a URI.
>     Commonjs implicitly adds a '.js' which suggests this maps to a REST
> construct.
>     I think it would be helpful to clarify the above literal, the,
>     any relation to javascript namespace and a mapping to server resources
> since there is
>     such an overlap with package management.
> 2. If the eagerness of the interpreter is determined by its implementation
>     we could have lots of indeterminism across interpreters. There should

Which sources of indeterminism do you foresee?
Is this indeterminism as apparent to a network observer or as apparent
to code running in the same interpreter?

[Kam] the network observer. A given interpreter may end up making lots of fetches 
or a few depending when it decided to resolve the import's.

>     probably be another construct that defines when resources are fetched.
>     I'm not sure if the interpreter shouldn't be influenced by the
> developer.

Could you rephrase this last sentence, please?

[Kam]  as an example. lets say a module contains 3 adapters:
one that uses jQuery, one that uses Ext and one that uses YUI.
A eager interpreter may fetch all three when evaluating the module.
Yet if the choice of what framework to use (jQuery, Ext or YUI) was 
determined by the developer/user early on, then the interpreter would 
fetch 2 frameworks without needing to. If the developer had a 
way to indicating to the interpreter that 2 of the frameworks weren't 
needed then the behavior of the interpreter would be predictable.

> Brendan, do you recall es4 where the concept of a unit was introduced?
> There was also some discussion where management and security
> where implicitly mapped to the '.' between identifier parts. I cannot find
> that reference.
> Kam
> ________________________________
> From: Mike Samuel <mikesamuel at>
> To: kkasravi <kkasravi at>
> Cc: es-discuss <es-discuss at>
> Sent: Fri, January 15, 2010 11:20:48 AM
> Subject: Re: Module system strawpersons
> 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
> with
>   (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
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list