Normative: Support other languages in ES module graphs

[linclark]

These changes are necessary to support modules written in statically typed languages in ES module graphs. I explain the motivation in slides I will be presenting at the May 2018 TC39 meeting.

This PR:

• Adds a Cyclic Module Record abstract subclass of the Abstract Module Record. This will be the parent class for Source Text Module Record and any other module types that can participate in cycles.
• Adds a subphase of instantiation which runs after the current instantiation algorithm. This allows statically typed languages that are in cycles with JavaScript modules to import functions from those JavaScript modules.

I expect to discuss this at the TC39 meeting that starts tomorrow, so this PR may change as a result of that discussion.

[allenwb]

"A framework that has only been used once is a buggy framework" Ralph Johnson at "Designing Reusable Designs" panel session, OOPSLA 1990.

The presentation you prepared for TC39 is most excellent! Thanks for this effort.

As the the original designer of the Module Record "class hierarchy" I have a few thoughts I wanted to share.

First off, when doing the initial design, I considered the circularity resolution and initialization semantics provided by SourceTextModuleRecords to be very specific to what today are called ESMs. Other languages and even other JavaScript module systems (eg, CJS) might have complete a completely different semantics for resolving/validating/linking/initializing their own module types (let's just call that their "module semantics" and let's call such non-ESM modules "foreign modules"). It wasn't at all clear that the module semantics of various foreign module systems could easily integrate into the ESM module semantics. So, I decided to keep the design simple by considering the import of a foreign module as if it was an atomic black box. From the perspective of the original ESM module semantics, a foreign module was viewed as an atomic opaque module that could only expose named bindings. The assumption was that any foreign inter-module semantics would be self-contained within the foreign language implementation. The methods of AbstractModuleRecord essentially define the minimal interface needed to incorporate such an atomic foreign module into the ESM module semantics. In particular, the original design make no provisions for foreign modules importing ESMs (or more generally any ES provided bindings) as the semantics of that was something that seemed like it would have to be designed on a case by case basis for each foreign language module semantics interface (for example, the type checking issues you mention in your presentation).

My interpretation of what you are proposing, goes beyond handling of circularities. What you are really saying is that you want to support a specific way to integrate foreign modules into the ESM module semantics. An integration that allows ECMAScript modules (not limited to ESMs) to dynamically integrate into a foreign module semantics. Essentially the mirror of how foreign modules were handled in my original design. Or, looking at it another way, you are trying to define a way to interweave the ESM module semantics and a specific subset of all possible foreign language module semantics.

Does this make sense? It probably does from the low level perspective of WebAssembly. It would be nice is have WebAssembly modules that essentially act as if they were ESMs. It is less clear to me that is makes as much sense from the perspective of static languages that might be compiled into WebAssembly. For example, consider C. Statically linking a set of C source files is semantically very different from dynamically loading and accessing a DLL from C code. In compiling C to WebAssembly i would expect that static linking would occur ahead of time producing a single opaque WebAssembly module and that any dynamic imports from the C code would be handled similarly to DLL access.

So, I think you are on a good track, but I think you need to be careful to not create the impression all languages that compile to WebAssembly must make their internal module semantics map onto the semantics you are providing.

One concrete suggestion, in your presentation you focus on cyclic modules and name your new abstract class "Cyclic Module Record". But, as I describe above, cycles are only part of the ESM module semantics that you are want to integrate into. Perhaps a different name would make that clearer. Something like, Bidirectional Module (a module that both creates and consumes ES bindings) or ESM-like module, or co-module, etc ???

So, great work. I'd be happy to chat sometime if you thing my perspective could be helpful.

Allen

[linclark]

Through some discussions with people on the WebAssembly side, we've been able to pare this down to just moving the cyclic dependency handling out to its own module record.

This PR was too hard to update cleanly, and I don't want to lose the history here by doing a force-update with the new version, so I'm going to close this one out. I've added a new PR that uses the new approach, #1311.