Skip to content
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.

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

change how ReturnIfAbrupt and its shorthands are specified #1573

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@michaelficarra
Copy link
Member

commented Jun 7, 2019

In #1570, we discussed how the way ReturnIfAbrupt and its shorthands are specified is unclear. I've made it clear that the ReturnIfAbrupt equivalence is on sequences of algorithm steps and the shorthand is a simple replacement in any context.

I've updated the ! shorthand in this PR as well, but in #1572 I give the option that we remove it, so we should resolve that first.

I recommend reading the current and proposed spec text separately to review. The diff will not be very helpful.

This will obsolete #1570.

@ljharb

ljharb approved these changes Jun 7, 2019

@ljharb ljharb requested review from zenparsing and tc39/ecma262-editors Jun 7, 2019

@michaelficarra

This comment has been minimized.

Copy link
Member Author

commented Jun 7, 2019

@ljharb I've moved the ! shorthand up to the "Implicit Completion Values" section for now while we decide its fate in #1572.

<emu-alg>
1. If _argument_ is an abrupt completion, return _argument_.
1. Else if _argument_ is a Completion Record, set _argument_ to _argument_.[[Value]].
1. Else, if _argument_ is a Completion Record, set _argument_ to _argument_.[[Value]].

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator
Suggested change
1. Else, if _argument_ is a Completion Record, set _argument_ to _argument_.[[Value]].
1. Else if _argument_ is a Completion Record, set _argument_ to _argument_.[[Value]].

(In an "Else if", we don't put a comma after the "Else".)

<emu-alg>
1. Let _result_ be AbstractOperation(ReturnIfAbrupt(_argument_)).
1. Let _result_ be _someValue_ if ReturnIfAbrupt(_someValue_.OperationName(_firstArgument_, _secondArgument_)) is *true*, and _someOtherValue_ otherwise.

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

Note that we don't have the syntax X if COND, and Y otherwise.

<emu-alg>
1. ReturnIfAbrupt(OperationName()).
</emu-alg>
<p>Similarly, for method application style, the step:</p>
<p>wherever it appears. Similarly, prefix `?` may be used to apply the ReturnIfAbrupt expansion to the result of applying a syntax-directed operation.</p>

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

Append "For example,"

<emu-alg>
1. ReturnIfAbrupt(_someValue_.OperationName()).
1. Let _result_ be SyntaxDirectedOperation of |NonTerminal| with arguments _firstArgument_ and _secondArgument_.
1. ReturnIfAbrupt(_result_).

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

This doesn't follow the given expansion. That would be

1. Let _result_ be ReturnIfAbrupt(SyntaxDirectedOperation of |NonTerminal| with arguments _firstArgument_ and _secondArgument_).
spec.html Outdated
<ul>
<li>*[before]*, if present, is any algorithm text that does not contain ReturnIfAbrupt.
<li>*[after]*, if present, is any algorithm text.
<li>_argument_ is any variable.

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

The spec calls them "aliases".

<emu-alg>
1. ReturnIfAbrupt(AbstractOperation()).
1. *[before]* ReturnIfAbrupt(AbstractOperation(*[arguments]*)) *[after]*

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

Rather than having 2 definitions, discriminated by the form of the argument, you could have one definition with a generalized argument.


<p>Invocations of abstract operations may be prefixed by `!` to indicate that the result will never be an abrupt completion and that the resulting Completion Record's [[Value]] field should be used in place of the return value of the operation.</p>
<emu-alg>
1. Let _val_ be ! OperationName().

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

As in the status quo, this is an illustrative example, not a real definition. You should maybe give it a proper definition as with 'ReturnIfAbupt'.

@@ -771,6 +771,27 @@ <h1>Implicit Completion Values</h1>
1. Return NormalCompletion(*undefined*).
</emu-alg>
<p>Any reference to a Completion Record value that is in a context that does not explicitly require a complete Completion Record value is equivalent to an explicit reference to the [[Value]] field of the Completion Record value unless the Completion Record is an abrupt completion.</p>

<p>Invocations of abstract operations may be prefixed by `!` to indicate that the result will never be an abrupt completion and that the resulting Completion Record's [[Value]] field should be used in place of the return value of the operation.</p>

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 18, 2019

Collaborator

I don't think the "!" stuff fits very well in the "Implicit Completion Values" clause. It makes more sense where it is now, in the same clause as "?". Instead of "ReturnIfAbrupt Shorthands", that clause could be called "Shorthands relating to completion records" or just "? and ! Shorthands".

Or split them into 2 clauses: "The ? Shorthand" and "The ! Shorthand".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.