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,
ModuleLoader/es6-module-loader, as the Loader in
Traceur, 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
ModuleLoader/es6-module-loader#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
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>
In 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, ModuleLoader/es6-module-loader, as the Loader in Traceur, 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 ModuleLoader/es6-module-loader#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