May 21, 22, 23 TC39 Meeting Notes

Andreas Rossberg rossberg at
Tue Jun 4 08:07:11 PDT 2013

On 4 June 2013 16:19, Kevin Smith <zenparsing at> wrote:
>> Well, it's unclear to me exactly what semantics Kevin was proposing,
>> but the current system has "export * from ..." and this introduces
>> many of the same problems once you import and export modules.
>> And the complexity of the static semantics is what I'm trying to point
>> out, fundamentally.
> We need nested modules, but I'm thinking that we would be okay disallowing
> the exporting of modules in the first pass.  If modules cannot be exported
> (and hence imported), are there still problems (with complexity or
> otherwise)?
> I'm still trying to get a handle on the problem or complexity which arises
> when adding the ability to export modules.  Is there a way that we can state
> the problem in terms of an algorithm (graph traversal, etc)?

With nesting the dependency graph between modules gets a second kind
of edge, because you then have dependencies of the kind 'imports-from'
as well as 'contains/exports'. And that introduces new potential for
cyclic dependencies.

But overall, it does not matter much. You can have cycles anyway, and
as long as every import-export edge has an explicit annotation about
what is imported (which is the case unless you add "import *"), so
that all scoping is apparent, you can always check all constraints by
two linear passes over the module structure that first collects
expected export sets and second validates them. By using a constraint-
or unification-based approach, you can do it in one pass.

I actually think that "export *" already subsumes all the complication
of nested modules, because it creates a similar (but more general)
kind of 'exports' dependency. In addition, validation now has to
happen in dependency order and/or deal with export cycles (and detect
non-wellfounded cycles).

The notorious "import *", however, is far worse. With that, you don't
generally know what's in scope before you know what any module name
refers to -- and vice versa! In general, resolving this requires an
algorithm with backtracking, which obviously is a no-go.


More information about the es-discuss mailing list