<div dir="ltr">Referencing the presentation at <a href="http://wiki.ecmascript.org/doku.php?id=meetings:meeting_mar_12_2013" target="_blank">http://wiki.ecmascript.org/doku.php?id=meetings:meeting_mar_12_2013</a>.<div><br>
</div><div>
The module loader proposal outlined in the presentation is looking pretty solid.  However, there is a weakness which I would like to point out.</div><div><br></div><div>The primary change in this proposal is a "link" hook, which takes source code and can return one of three different things:</div>

<div><br></div><div>1) A Module object.</div><div>2) An object containing a list of dependancies and a factory hook which is called when the dependencies are satisfied and must return a Module object.</div><div>3)  undefined, in which case the engine compiles and links the source, producing a module instance.</div>
<div><br></div><div style>In the presentation, there is an example of loading require-based Node modules using the link hook.  If the module is a Node module, then the source code is eval'ed and a Module object is created based on the result of that execution:</div>
<div style><br></div><div style>    System.link = function(source, options) {</div><div style>      if (options.metadata === "node") {</div><div style>        // Execute `source` in a new loader context and create a</div>
<div style>        // Module object from the result</div><div style>        return new Module(extractNodeExports(this, source));</div><div style>      }</div><div style>    }; </div><div style><br></div><div style>The problem is that the `options.metadata === "node"` test is hand-waiving.  In a mixed environment where a module may be an ES6 module or a legacy Node module, how is the loader supposed to know how to link it?  Ideally, everything will "just work", so that legacy modules can be used transparently alongside ES6 modules.</div>
<div style><br></div><div style>A reasonable heuristic is to only use the legacy module linking algorithm if there are no import or export declarations in the source code.  However, obtaining that information requires parsing the source.  Even using a C++ parser, it seems wasteful to parse every module's source code *twice*.</div>
<div style><br></div><div style>There are different ways to address this, but we can note two things:</div><div style><br></div><div style>1) There will never be a need to override the "link" behavior for an actual ES6 module.  That is, a module whose source code contains import and export declarations.  In that case, all of the relevant linking information is already contained directly within the source code.</div>
<div style><br></div><div style>2) Regardless of whether linking is overridden or not for a given source, that source *must* be valid ES6 code.</div><div style><br></div><div style>Taking these two points together, it is sufficient for our interoperability needs to redefine the "link" hook as follows:</div>
<div style><br></div><div style>    - The "translate" hook is executed, producing a string `finalSource`.</div><div style>    - `finalSource` is parsed by the ES engine.</div><div style>    - If `finalSource` contains import declarations or export declarations,</div>
<div style>      or if there is no "link" hook defined:</div><div style>        - `finalSource` is executed and linked by the ES engine.</div><div style>    - Otherwise:</div><div style>        - Call the "link" hook with `finalSource` as the first argument.</div>
<div style>        - The "link" hook will asynchronously return a Module object.</div><div style><br></div><div style>A diagram:  <a href="https://docs.google.com/drawings/d/1WfMhFq_kcyA1kS47V-M8odteA63IjLHAbNkqRynfIDg/edit?usp=sharing">https://docs.google.com/drawings/d/1WfMhFq_kcyA1kS47V-M8odteA63IjLHAbNkqRynfIDg/edit?usp=sharing</a><br>
</div><div style><br></div><div style>Yes, this approach is a little hacky, but so is the requirement:  that we must support transparent interoperability with a legacy module system.  Note that with this approach, we will still end up parsing code for legacy modules twice, but (a) it will be parsed by the C++ engine and (b) the cost will be only be paid for legacy code.</div>
<div style><br></div><div style>Thoughts?  Holes?</div><div style><br></div><div style>Thanks for your time,</div><div style><br></div><div style>{ Kevin }</div></div>