Loader.parse ?

John Barton johnjbarton at google.com
Sat Jul 5 09:07:18 PDT 2014


In
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instantiatesucceeded-instantiateresult-functions
,

15.2.4.5.3 InstantiateSucceeded(instantiateResult) Functions

The step number 4 reads:
-----
If instantiateResult is undefined, then

Let body be the result of parsing load.[[Source]], interpreted as UTF-16
encoded Unicode text as described in 10.1.1, using Module as the goal
symbol. Throw a SyntaxError exception if the parse fails or if any static
semantics errors are detected.
Set load.[[Body]] to body.
Set load.[[Kind]] to declarative.
Let depsList be the ModuleRequests of body.
----

While trying to use es6-module-loader,
https://github.com/ModuleLoader/es6-module-loader/, as the Loader in
Traceur, https://github.com/google/traceur-compiler/, rather than our
current TraceurLoader, it became clear that the above step 4 would be
architecturally clearer if it were a hook comparable to
normalize/locate/fetch...  For example:
    parse(load) -> depsList
nicely fulfills the requirements of step 4.  The loader.js file in
https://github.com/ModuleLoader/es6-module-loader/pull/174 shows the
consequences in source that follows the spec.

Adding `parse` as a Loader hook allows customization of the declarative
path of the Loader.   This mechanism is a good fit for Traceur, providing
evidence that this API would prove useful.

Please consider adding a `parse()` hook to the Loader.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140705/7a542fb2/attachment.html>


More information about the es-discuss mailing list