Skip to content

Editorial: remove ReturnIfAbrupt and specify ! and ? directly #3705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 4, 2025
Merged

Editorial: remove ReturnIfAbrupt and specify ! and ? directly #3705

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8c9cc3b
Editorial: specify evaluation order for expressions (#3705)
bakkot Nov 4, 2025
70b0872
Editorial: remove ReturnIfAbrupt and specify `!` and `?` directly (#3…
bakkot Nov 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
99 changes: 44 additions & 55 deletions spec.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -997,6 +997,25 @@
<p>Algorithm steps may declare named aliases for any value using the form “Let _x_ be _someValue_”. These aliases are reference-like in that both _x_ and _someValue_ refer to the same underlying data and modifications to either are visible to both. Algorithm steps that want to avoid this reference-like behaviour should explicitly make a copy of the right-hand side: “Let _x_ be a copy of _someValue_” creates a shallow copy of _someValue_.</p>
<p>Once declared, an alias may be referenced in any subsequent steps and must not be referenced from steps prior to the alias's declaration. Aliases may be modified using the form “Set _x_ to _someOtherValue_”.</p>

<emu-clause id="sec-evaluation-order">
<h1>Evaluation Order</h1>
<p>When complex expressions appear in algorithm steps, these are to be understood as being evaluated in a left-to-right, inside-to-outside order. For example, the step</p>
<emu-alg example>
1. Return A(B(), C.[[D]]) + E(F()).
</emu-alg>
<p>is equivalent to</p>
<emu-alg example>
1. Let _tmp1_ be B().
1. Let _tmp2_ be C.[[D]].
1. Let _tmp3_ be A(_tmp1_, _tmp2_).
1. Let _tmp4_ be F().
1. Let _tmp5_ be E(_tmp4_).
1. Let _tmp6_ be _tmp3_ + _tmp5_.
1. Return _tmp6_.
</emu-alg>
<p>where the various _tmpN_ aliases are ephemeral and visible only in these steps.</p>

Check warning on line 1016 in spec.html

View workflow job for this annotation

GitHub Actions / check for newly-introduced spelling errors

Potential Typo 

"tmpN" is not a previously used word or composed of previously used words. Perhaps it is a typo?
</emu-clause>

<emu-clause id="sec-algorithm-conventions-abstract-operations">
<h1>Abstract Operations</h1>
<p>In order to facilitate their use in multiple parts of this specification, some algorithms, called <dfn>abstract operations</dfn>, are named and written in parameterized functional form so that they may be referenced by name from within other algorithms. Abstract operations are typically referenced using a functional application style such as OperationName(_arg1_, _arg2_). Some abstract operations are treated as polymorphically dispatched methods of class-like specification abstractions. Such method-like abstract operations are typically referenced using a method application style such as _someValue_.OperationName(_arg1_, _arg2_).</p>
Expand Down Expand Up @@ -1060,74 +1079,44 @@
</emu-alg>
</emu-clause>

<emu-clause id="sec-returnifabrupt" aoid="ReturnIfAbrupt">
<h1>ReturnIfAbrupt</h1>
<p>Algorithms steps that say or are otherwise equivalent to:</p>
<emu-clause id="sec-shorthands-for-unwrapping-completion-records" oldids="sec-returnifabrupt">
<h1>Shorthands for Unwrapping Completion Records</h1>
<p>Prefix `?` and `!` are used as shorthands which unwrap Completion Records. `?` is used to propagate an abrupt completion to the caller, or otherwise to unwrap a normal completion. `!` is used to assert that a Completion Record is normal and unwrap it. Formally, the step</p>
<emu-alg example>
1. ReturnIfAbrupt(_argument_).
1. Let _result_ be ? _record_.
</emu-alg>
<p>mean the same thing as:</p>
<p>is equivalent to</p>
<emu-alg example>
1. Assert: _argument_ is a Completion Record.
1. If _argument_ is an abrupt completion, return Completion(_argument_).
1. Else, set _argument_ to _argument_.[[Value]].
1. Assert: _record_ is a Completion Record.
1. If _record_ is an abrupt completion, return _record_.
1. Let _result_ be _record_.[[Value]].
</emu-alg>
<p>Algorithms steps that say or are otherwise equivalent to:</p>
<p>Likewise, the step</p>
<emu-alg example>
1. ReturnIfAbrupt(AbstractOperation()).
1. Let _result_ be ! _record_.
</emu-alg>
<p>mean the same thing as:</p>
<emu-alg example>
1. Let _hygienicTemp_ be AbstractOperation().
1. Assert: _hygienicTemp_ is a Completion Record.
1. If _hygienicTemp_ is an abrupt completion, return Completion(_hygienicTemp_).
1. Else, set _hygienicTemp_ to _hygienicTemp_.[[Value]].
</emu-alg>
<p>Where _hygienicTemp_ is ephemeral and visible only in the steps pertaining to ReturnIfAbrupt.</p>
<p>Algorithms steps that say or are otherwise equivalent to:</p>
<emu-alg example>
1. Let _result_ be AbstractOperation(ReturnIfAbrupt(_argument_)).
</emu-alg>
<p>mean the same thing as:</p>
<emu-alg example>
1. Assert: _argument_ is a Completion Record.
1. If _argument_ is an abrupt completion, return Completion(_argument_).
1. Else, set _argument_ to _argument_.[[Value]].
1. Let _result_ be AbstractOperation(_argument_).
</emu-alg>
</emu-clause>

<emu-clause id="sec-returnifabrupt-shorthands">
<h1>ReturnIfAbrupt Shorthands</h1>
<p>Invocations of abstract operations and syntax-directed operations that are prefixed by `?` indicate that ReturnIfAbrupt should be applied to the resulting Completion Record. For example, the step:</p>
<emu-alg example>
1. ? OperationName().
</emu-alg>
<p>is equivalent to the following step:</p>
<emu-alg example>
1. ReturnIfAbrupt(OperationName()).
</emu-alg>
<p>Similarly, for method application style, the step:</p>
<emu-alg example>
1. ? _someValue_.OperationName().
</emu-alg>
<p>is equivalent to:</p>
<p>is equivalent to</p>
<emu-alg example>
1. ReturnIfAbrupt(_someValue_.OperationName()).
1. Assert: _record_ is a normal completion.
1. Let _result_ be _record_.[[Value]].
</emu-alg>
<p>Similarly, prefix `!` is used to indicate that the following invocation of an abstract or syntax-directed operation will never return an abrupt completion and that the resulting Completion Record's [[Value]] field should be used in place of the return value of the operation. For example, the step:</p>
<p>When `?` or `!` is used in any other context, first apply the rewrite given in <emu-xref href="#sec-evaluation-order" title></emu-xref> until this rule can be applied, then apply this rule. For example, the step</p>
<emu-alg example>
1. Let _val_ be ! OperationName().
1. Perform AO(? Other()).
</emu-alg>
<p>is equivalent to the following steps:</p>
<p>can be rewritten to</p>
<emu-alg example>
1. Let _val_ be OperationName().
1. Assert: _val_ is a normal completion.
1. Set _val_ to _val_.[[Value]].
1. Let _tmp1_ be Other().
1. Let _tmp2_ be ? _tmp1_.
1. Perform AO(_tmp2_).
</emu-alg>
<p>Syntax-directed operations for runtime semantics make use of this shorthand by placing `!` or `?` before the invocation of the operation:</p>
<p>which in turn expands to</p>
<emu-alg example>
1. Perform ! SyntaxDirectedOperation of |NonTerminal|.
1. Let _tmp1_ be Other().
1. Assert: _tmp1_ is a Completion Record.
1. If _tmp1_ is an abrupt completion, return _tmp1_.
1. Let _tmp2_ be _tmp1_.[[Value]].
1. Perform AO(_tmp2_).
</emu-alg>
</emu-clause>

Expand Down
Loading