Skip to content

Editorial: refactor classic and module scripts to be more alike#2972

Merged
domenic merged 3 commits intomasterfrom
module-fixes-3
Sep 6, 2017
Merged

Editorial: refactor classic and module scripts to be more alike#2972
domenic merged 3 commits intomasterfrom
module-fixes-3

Conversation

@domenic
Copy link
Copy Markdown
Member

@domenic domenic commented Aug 28, 2017

This makes "create a classic script" work the same as "create a module
script". Both now parse source text into the appropriate record (viz.
Script Record or Source Text Module Record), storing the result, or any
parse error, for later use by "run a X script".

As a consequence, this expands the base "script" struct to include
"record" and "parse error" fields, which were previously
module-specific.

In general, this alignment will help greatly when working on dynamic
import(), which per
https://github.com/tc39/proposal-dynamic-import/blob/23cf15a8ccef0c7174b504b33fb6b2b9be1ebecd/HTML%20Integration.md
will move more things into the shared base struct.

Note that for now, "parse error" is somewhat of a misnomer for modules,
as we propagate dependency errors into this field. This is hinted at by
leaving the name for that algorithm, "set a pre-instantiation error",
intact. We anticipate clearing up this confusion in subsequent commits,
by changing error propagation, but this was left as such in order to
keep this commit purely editorial.

Along the way, this:

  • Fixes a few remaining references to module trees, as opposed to module
    graphs.
  • Changes "muted errors" from a flag into a boolean.
  • Modernizes the algorithm style for both create algorithms, making them
    take named parameters, stop using goto-style jumps, and use booleans
    instead of flags.
  • Fixes the spec to report errors while inside the "prepare to run a
    script" / "clean up after running script" block.

@nyaxt or @hiroshige-g to review.

On top of #2971.

Marking "do not merge yet" as this should probably only be merged as part of the final module revisions package. That is, more PRs are coming on top of this one. But this seems like a nice separate chunk of work, editorial only, which can be reviewed independently.

@domenic domenic added clarification Standard could be clearer do not merge yet Pull request must not be merged per rationale in comment topic: script labels Aug 28, 2017
@domenic
Copy link
Copy Markdown
Member Author

domenic commented Aug 29, 2017

Preview of the output with these changes: https://module-fixes-creation-vaieylcnns.now.sh

Places to review are "create a module script", "create a classic script", the definition of the "script" struct, "run a classic script", and "run a module script".

source Outdated

</dd>
<dd><p>Either a <span>Script Record</span>, for <span data-x="classic script">classic
scripts</span>, or a <span>Source Text Module Record</span>, for <span data-x="module
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This or seems redundant with the final or.

@domenic domenic removed the do not merge yet Pull request must not be merged per rationale in comment label Aug 31, 2017
@domenic
Copy link
Copy Markdown
Member Author

domenic commented Aug 31, 2017

I have confirmed this provides a stable foundation going forward, so removing "do not merge yet"; review appreciated.

@domenic
Copy link
Copy Markdown
Member Author

domenic commented Aug 31, 2017

I guess it should still be "do not merge yet" since it needs to be on top of #2971.

@domenic domenic added the do not merge yet Pull request must not be merged per rationale in comment label Aug 31, 2017
data-x="js-ScriptEvaluation">ScriptEvaluation</span>(<var>result</var>).</p></li>
<ol>
<li>
<p>If <var>rethrow errors</var> is true and <var>script</var>'s <span>muted
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be "muted errors is false"?
(The condition here and the condition at Lines 87206--87208 are the same and at least either of them should be fixed.)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thank you!! Pushing fix now.

source Outdated
<li>
<p><i>Error</i>: At this point <var>result</var> must be an exception. Perform the following
steps:</p>
<li><p>Rethrow <var>evaluationStatus</var>.</p></li>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we rethrow evaluationStatus.[[Value]] instead of evaluationStatus?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that's probably more understandable. This interface between the ES spec and HTML is a bit confusing as to what terminology to use; I meant "rethrow evaluationStatus" as "return evaluationStatus, which is equivalent to rethrowing its [[Value]]". But your phrasing is better. I will change.

@domenic
Copy link
Copy Markdown
Member Author

domenic commented Sep 6, 2017

@hiroshige-g does this LGTY? (When rebased on #2971, if #2971 LGTY.)

@hiroshige-g
Copy link
Copy Markdown
Contributor

lgtm, once rebased.

Copy link
Copy Markdown
Member

@foolip foolip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rs=me

This makes "create a classic script" work the same as "create a module
script". Both now parse source text into the appropriate record (viz.
Script Record or Source Text Module Record), storing the result, or any
parse error, for later use by "run a X script".

As a consequence, this expands the base "script" struct to include
"record" and "parse error" fields, which were previously
module-specific.

In general, this alignment will help greatly when working on dynamic
import(), which per
https://github.com/tc39/proposal-dynamic-import/blob/23cf15a8ccef0c7174b504b33fb6b2b9be1ebecd/HTML%20Integration.md
will move more things into the shared base struct.

Note that for now, "parse error" is somewhat of a misnomer for modules,
as we propagate dependency errors into this field. This is hinted at by
leaving the name for that algorithm, "set a pre-instantiation error",
intact. We anticipate clearing up this confusion in subsequent commits,
by changing error propagation, but this was left as such in order to
keep this commit purely editorial.

Along the way, this:

* Fixes a few remaining references to module trees, as opposed to module
  graphs.
* Changes "muted errors" from a flag into a boolean.
* Modernizes the algorithm style for both create algorithms, making them
  take named parameters, stop using goto-style jumps, and use booleans
  instead of flags.
* Fixes the spec to report errors while inside the "prepare to run a
  script" / "clean up after running script" block.
* Fixes several wrong variable references within these algorithms.
@domenic domenic removed the do not merge yet Pull request must not be merged per rationale in comment label Sep 6, 2017
@domenic domenic merged commit dce999a into master Sep 6, 2017
@domenic domenic deleted the module-fixes-3 branch September 6, 2017 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clarification Standard could be clearer topic: script

Development

Successfully merging this pull request may close these issues.

4 participants