inadequate .[[Value]] after ReturnIfAbrupt in 15.2.1.20

[kotarondo]

In the following Evaluation algorithm, sl.[[Value]] in the last line should be sl because sl is already a completion's [[Value]] after ReturnIfAbrupt(sl).

15.2.1.20 Runtime Semantics: Evaluation
ModuleItemList: ModuleItemList ModuleItem
 1. Let sl be the result of evaluating ModuleItemList.
 2. ReturnIfAbrupt(sl).
 3. Let s be the result of evaluating ModuleItem.
 4. Return Completion(UpdateEmpty(s, sl.[[Value]])).

[ljharb]

Doesn't ReturnIfAbrupt(sl) become the value? I don't think it mutates the fictional sl binding.

[ljharb]

Doesn't ReturnIfAbrupt(sl) become the value? I don't think it mutates the fictional sl binding.

[kotarondo]

The Definition of ReturnIfAbrupt:

5.2.3.3 ReturnIfAbrupt
Algorithms steps that say or are otherwise equivalent to:

ReturnIfAbrupt(argument).
mean the same thing as:

If argument is an abrupt completion, return argument.
Else if argument is a Completion Record, let argument be argument.[[Value]].

In above case, step 2 means:

If sl is an abrupt completion, return sl.
Else if sl is a Completion Record, let sl be sl.[[Value]].

[kotarondo]

The Definition of ReturnIfAbrupt:

5.2.3.3 ReturnIfAbrupt
Algorithms steps that say or are otherwise equivalent to:

ReturnIfAbrupt(argument).
mean the same thing as:

If argument is an abrupt completion, return argument.
Else if argument is a Completion Record, let argument be argument.[[Value]].

In above case, step 2 means:

If sl is an abrupt completion, return sl.
Else if sl is a Completion Record, let sl be sl.[[Value]].

[ljharb]

Ah, fair point. That seems like a confusing way for the spec to be worded, but given that, I think you are correct.

[ljharb]

Ah, fair point. That seems like a confusing way for the spec to be worded, but given that, I think you are correct.

[jmdyck]

That seems like a confusing way for the spec to be worded

(I think it would be less confusing with the proposal of Issue #497.)

[jmdyck]

That seems like a confusing way for the spec to be worded

(I think it would be less confusing with the proposal of Issue #497.)