Module system strawpersons

Kam Kasravi kamkasravi at
Mon Jan 18 13:27:10 PST 2010


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.


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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list