Editorial: do not use "Return" to transfer control between execution contexts #2429

bakkot · 2021-06-06T19:19:12Z

Depends on #2413. Also I'm not 100% sure this all makes sense, so marking as a draft for now.

TODO: ensure the Let steps are on their own line (if coherent).

brabalan · 2021-06-07T06:45:20Z

spec.html

-          1. Set the code evaluation state of _asyncContext_ such that when evaluation is resumed with a Completion _completion_, the following steps of the algorithm that invoked Await will be performed, with _completion_ available.
-          1. Return.
-          1. NOTE: This returns to the evaluation of the operation that had most previously resumed evaluation of _asyncContext_.
+          1. Let _outerContext_ be the running execution context.


Could you name _outerContext in the previous step (the one where _asyncContext is removed from the stack) and thus skip this step?

brabalan · 2021-06-07T06:46:38Z

spec.html

-            1. NOTE: This returns to the evaluation of the |YieldExpression| that originally called this abstract operation.
-          1. Return NormalCompletion(_iterNextObj_).
-          1. NOTE: This returns to the evaluation of the operation that had most previously resumed evaluation of _genContext_.
+          1. Let _outerContext_ be the running execution context.


Same comment as above, _outerContext_ could be named in the previous step.

brabalan · 2021-06-07T06:50:24Z

spec.html

-              1. NOTE: When the above step returns, it returns to the evaluation of the |YieldExpression| production that originally called this abstract operation.
-            1. Return *undefined*.
-            1. NOTE: This returns to the evaluation of the operation that had most previously resumed evaluation of _genContext_.
+            1. Let _outerContext_ be the running execution context.


Same as above.

jmdyck · 2021-06-07T15:00:05Z

spec.html

+          1. NOTE: _outerContext_ is the execution context for the evaluation of the operation that had most previously resumed evaluation of _asyncContext_.
+          1. Resume _outerContext_.
+          1. Assert: If control reaches here, _asyncContext_ is once again the running execution context.
+          1 Let _completion_ be the Completion Record with which _asyncContext_ was resumed.


Suggested change

1 Let _completion_ be the Completion Record with which _asyncContext_ was resumed.

1. Let _completion_ be the Completion Record with which _asyncContext_ was resumed.

jmdyck · 2021-06-07T15:03:18Z

spec.html

+          1. Let _outerContext_ be the running execution context.
+          1. NOTE: _outerContext_ is the execution context for the evaluation of the operation that had most previously resumed evaluation of _asyncContext_.
+          1. Resume _outerContext_.
+          1. Assert: If control reaches here, _asyncContext_ is once again the running execution context.


Suggested change

1. Assert: If control reaches here, _asyncContext_ is once again the running execution context.

1. Assert: If control reaches here, then _asyncContext_ is once again the running execution context.

jmdyck · 2021-06-07T15:03:44Z

spec.html

+          1. Let _outerContext_ be the running execution context.
+          1. NOTE: _outerContext_ is the execution context for the evaluation of the operation that had most previously resumed evaluation of _genContext_.
+          1. Resume _outerContext_ passing NormalCompletion(_iterNextObj_).
+          1. Assert: If control reaches here, _genContext_ is once again the running execution context.


Suggested change

1. Assert: If control reaches here, _genContext_ is once again the running execution context.

1. Assert: If control reaches here, then _genContext_ is once again the running execution context.

jmdyck · 2021-06-07T15:04:13Z

spec.html

+            1. Let _outerContext_ be the running execution context.
+            1. NOTE: _outerContext_ is the execution context for the evaluation of the operation that had most previously resumed evaluation of _genContext_.
+            1. Resume _outerContext_.
+            1. Assert: If control reaches here, _genContext_ is once again the running execution context.


Suggested change

1. Assert: If control reaches here, _genContext_ is once again the running execution context.

1. Assert: If control reaches here, then _genContext_ is once again the running execution context.

jmdyck · 2021-06-07T18:31:16Z

spec.html

-            1. Once a generator enters the ~completed~ state it never leaves it and its associated execution context is never resumed. Any execution state associated with _generator_ can be discarded at this point.
-            1. If _result_.[[Type]] is ~normal~, let _resultValue_ be *undefined*.
-            1. Else if _result_.[[Type]] is ~return~, let _resultValue_ be _result_.[[Value]].
+            1. NOTE: once a generator enters the ~completed~ state it never leaves it and its associated execution context is never resumed. Any execution state associated with _generator_ can be discarded at this point.


Suggested change

1. NOTE: once a generator enters the ~completed~ state it never leaves it and its associated execution context is never resumed. Any execution state associated with _generator_ can be discarded at this point.

1. NOTE: Once a generator enters the ~completed~ state it never leaves it and its associated execution context is never resumed. Any execution state associated with _generator_ can be discarded at this point.

…contexts

jmdyck · 2022-02-15T04:53:40Z

spec.html

-          1. Return.
-          1. NOTE: This returns to the evaluation of the operation that had most previously resumed evaluation of _asyncContext_.
+          1. Let _outerContext_ be the running execution context.
+          1. NOTE: _outerContext_ is the execution context for the evaluation of the operation that had most previously resumed evaluation of _asyncContext_.


It's unclear what "most previously" is supposed to mean.

If it means "the longest ago", then that's wrong, because the execution context that first resumed evaluation of asyncContext isn't even necessarily on the stack, let alone in that position on the stack.

And if it means "most recently", then that got a problem too. It's true that, in the status quo, the most recent Resume the suspended evaluation of _asyncContext_ step must have come from the execution context that's below it on the stack. However, this PR introduces "resume" steps that go in the 'other direction', so if asyncContext's function itself calls an Async/GeneratorFunction, then it may have been resumed several times since outerContext resumed it.

So unless you want to introduce terminology that distinguishes the two 'directions' of resumes, I think it might be hard to describe how outerContext relates to asyncContext (other than being directly below it on the stack, of course, but that isn't really NOTE-worthy).

jmdyck · 2022-02-15T06:04:59Z

spec.html

-          1. Set the code evaluation state of _asyncContext_ such that when evaluation is resumed with a Completion _completion_, the following steps of the algorithm that invoked Await will be performed, with _completion_ available.
-          1. Return.
-          1. NOTE: This returns to the evaluation of the operation that had most previously resumed evaluation of _asyncContext_.
+          1. Let _outerContext_ be the running execution context.


Currently, the spec only uses "outer" when talking about environments, which is appropriate because we think of outer and inner scopes. But for these execution contexts, outer/inner doesn't seem like the right metaphor. Elsewhere, the spec calls them "caller" + "callee". (Which makes sense, though the fact that they only differ by one letter makes them a bit hard to distinguish visually.)

bakkot · 2023-01-18T23:13:08Z

Closing in favor of #2665 etc.

brabalan reviewed Jun 7, 2021

View reviewed changes

jmdyck requested changes Jun 7, 2021

View reviewed changes

jmdyck reviewed Jun 7, 2021

View reviewed changes

bakkot mentioned this pull request Jun 11, 2021

Editorial: describe behavior for algorithms without a "Return" #2397

Closed

bakkot force-pushed the rewrite-asyncgenerator-state-machine branch from d17e46d to 18100ca Compare July 4, 2021 23:11

ljharb force-pushed the rewrite-asyncgenerator-state-machine branch from 18100ca to f469441 Compare July 7, 2021 23:45

Base automatically changed from rewrite-asyncgenerator-state-machine to master July 7, 2021 23:50

bakkot force-pushed the execution-context-return branch 2 times, most recently from 525c4d7 to 6a7e4a6 Compare July 25, 2021 00:40

bakkot mentioned this pull request Aug 23, 2021

Normative: phrase tail calls as discarding resources rather than popping execution context stack #2495

Merged

bakkot added 2 commits October 28, 2021 07:35

Editorial: do not use "Return" to transfer control between execution …

d5e4078

…contexts

address jmdyck comments

177b3eb

ljharb force-pushed the execution-context-return branch from 6a7e4a6 to 177b3eb Compare October 28, 2021 14:35

bakkot mentioned this pull request Dec 9, 2021

Editorial: Can-call-user-code annotation #2548

Merged

bakkot mentioned this pull request Jan 11, 2022

Editorial: make suspension of resumable execution contexts explicit #2618

Open

jmdyck mentioned this pull request Feb 15, 2022

Editorial: Eliminate weird Return notes #2665

Merged

jmdyck reviewed Feb 15, 2022

View reviewed changes

jmdyck mentioned this pull request Mar 3, 2022

Editorial: Use Abstract Closure to set the code eval state #2681

Merged

bakkot closed this Jan 18, 2023

ljharb deleted the execution-context-return branch January 18, 2023 23:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editorial: do not use "Return" to transfer control between execution contexts #2429

Editorial: do not use "Return" to transfer control between execution contexts #2429

bakkot commented Jun 6, 2021 •

edited

Loading

brabalan Jun 7, 2021

brabalan Jun 7, 2021

brabalan Jun 7, 2021

jmdyck Jun 7, 2021

jmdyck Jun 7, 2021

jmdyck Jun 7, 2021

jmdyck Jun 7, 2021

jmdyck Jun 7, 2021

jmdyck Feb 15, 2022 •

edited

Loading

jmdyck Feb 15, 2022

bakkot commented Jan 18, 2023

	1 Let _completion_ be the Completion Record with which _asyncContext_ was resumed.
	1. Let _completion_ be the Completion Record with which _asyncContext_ was resumed.

	1. Assert: If control reaches here, _asyncContext_ is once again the running execution context.
	1. Assert: If control reaches here, then _asyncContext_ is once again the running execution context.

	1. Assert: If control reaches here, _genContext_ is once again the running execution context.
	1. Assert: If control reaches here, then _genContext_ is once again the running execution context.

	1. NOTE: once a generator enters the ~completed~ state it never leaves it and its associated execution context is never resumed. Any execution state associated with _generator_ can be discarded at this point.
	1. NOTE: Once a generator enters the ~completed~ state it never leaves it and its associated execution context is never resumed. Any execution state associated with _generator_ can be discarded at this point.

Editorial: do not use "Return" to transfer control between execution contexts #2429

Editorial: do not use "Return" to transfer control between execution contexts #2429

Conversation

bakkot commented Jun 6, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmdyck Feb 15, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bakkot commented Jan 18, 2023

bakkot commented Jun 6, 2021 •

edited

Loading

jmdyck Feb 15, 2022 •

edited

Loading