Module system strawpersons

Mike Samuel mikesamuel at
Mon Jan 18 14:44:48 PST 2010

2010/1/18 Kam Kasravi <kamkasravi at>:
> Hi Mike
> The former but not in the way you've described. Rather
> module A:
> this.getB= function() {
>   return new (import 'B')();
> }
> module B:
> this.getA = function() {
>   return new (import 'A')();
> }
> If modules eagerly resolve imports then the above circular dependency would
> be a problem.
> If modules lazily resolve imports then the above circular dependency would
> be ok.
> If catch-alls were used then proxy's would be used and the circular
> dependency would be ok.
> Current js has many examples of circular dependencies which are resolved by
> lazy evaluation.

Ihab's proposal allows eager fetching, and mandates lazy
instantiation, so the above example is not a problem with Ihab's

> Kam
> ________________________________
> From: Mike Samuel <mikesamuel at>
> To: Kam Kasravi <kamkasravi at>
> Cc: Andy Chu <andy at>; kkasravi <kkasravi at>; Brendan Eich
> <brendan at>; es-discuss <es-discuss at>
> Sent: Mon, January 18, 2010 1:50:15 PM
> Subject: Re: Module system strawpersons
> I don't quite understand what is meant by circular dependencies in this
> context.
> Are you talking about the graph of imports, or the graph of module
> instances?
> If the former, how is it a problem?
> If the latter, how could it occur without explicit user intent : a
> module explicitly passing itself to a dependency?
> E.g. in the former
>   // fib.js
>   var self = (import "fib.js");
>   if (n < 2) { return n; }
>   return self({ n: n - 2 }) + self({ n : n - 1 });
> a module imports itself, and recursively invokes separate instances
> which is stupid but does not result in a module being observed in a
> partially initialized state.
> In the latter:
>     // foo.js
>     var otherModuleMaker = (import "bar.js")({ baz: this });
> module foo is explicitly allowing otherModuleMaker to observe it in an
> uninitialized state.
> 2010/1/18 Kam Kasravi <kamkasravi at>:
>> Andy
>> yes I was referring to the circular dependency issue.
>> Catch-alls would be useful for this, though it would be nice if
>> they were automated, eg returning a proxy until the module was used.
>> Doing it manually by developer would be too difficult.
>> I realize modules are intended to just satisfy a function body and
>> can be initialized as objects or called as functions, but since they
>> have strong container semantics I wonder if they should
>> have more than just an 'id' especially if they provide a gateway
>> to what else is in the directory as in commonjs.
>> Kam
>> ________________________________
>> From: Andy Chu <andy at>
>> To: Kam Kasravi <kamkasravi at>
>> Cc: Brendan Eich <brendan at>; kkasravi <kkasravi at>;
>> es-discuss <es-discuss at>
>> Sent: Mon, January 18, 2010 12:40:35 PM
>> Subject: Re: Module system strawpersons
>> On Mon, Jan 18, 2010 at 10:29 AM, Kam Kasravi <kamkasravi at>
>> wrote:
>>> Yes, that looks right, I also remember a reference to the 'dot' notation
>>> where namespace
>>> access would be arbitrated implicitly by objects representing the '.' It
>>> may
>>> have been in
>>> one of Lars Hansen papers on gradual typing. In any case there was some
>>> good
>>> discussion
>>> on meta-level objects and controlling capabilities or access.
>>> Was there any discussion in the past about parameterized modules or
>>> units where recursively nested modules/units were brought up? If two
>>> modules
>>> refer to each other
>>> and all imports are resolved eagerly then I think this would be a problem
>>> where use cases would
>>> abound.
>> What are you referring to here?  I think you are hinting at the
>> problem of circular dependencies using "import" semantics like Python
>> and CommonJS.  Right now if you have mutually recursive modules, you
>> get partially initialized modules, because the "program counter" just
>> follows every require().  The CommonJS spec specifically allows the
>> partially initialized modules I think.
>> Personally I try to break up circular dependencies, but this behavior
>> is not very friendly, so I think it would be better if Harmony
>> supported circular dependencies in a more "correct" way.  So this is
>> an advantage of the "makers" style semantics (separating module
>> definition and configuration).
>> The Newspeak paper talks explicitly about this:
>> If you are initializing modules in topological order, and there is a
>> circular dependency between A and B, he says to just make a dummy
>> proxy object for B to pass into A, initialize A, and then initialize
>> B.
>> That also reminds me that a good use case for catchalls is making
>> module-like objects.  I haven't seen any discussions of the 2 together
>> but it's definitely worth thinking about how they interact.
>> Andy
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list