Editorial: Model execution context as a record

[jmdyck]

Resolves the first comment in issue #1742

I believe this PR is complete in the sense that it would leave the spec in a consistent state. However, there are various further changes you might want, so it's currently a Draft PR.

• I introduced the term ExecutionContext Record, but left some occurrences of execution context. You might prefer to get rid of execution context entirely.

• I changed the caption text of the three Fields tables, but not their id attributes.

• The status quo creates the context and then separately sets each of its components. I kept that format, but you might prefer the use of a record "literal" to define it all in one step.
  [Later: @bakkot prefers it as-is.]

• Where the status quo refers to the running execution context's SomethingOrOther, I introduced a step Let _runningContext_ be the running execution context and then referred to _runningContext_.[[SomethingOrOther]]. You might prefer to introduce a compact way to say "the running execution context". (About the only precedent for this is the use of NewTarget in algorithms.)
  [Later: @syg suggests "the [[SomethingOrOther]] field of the running execution context"]
  [Even later: settle on "the running execution context's [[SomethingOrOther]]"]

• When we define Additional Fields elsewhere in the spec (for Environment Records and Module Records), they're aligned with a (quasi) subtype hierarchy. This sort of works for ExecutionContext Record and ECMAScript code ExecutionContext Record, but not for Generator ExecutionContext Record: it's difficult to see the latter as a subtype. An ExecutionContext Record that represents the evaluation of a generator object is created as an ECMAScript code ExecutionContext Record (not a Generator ExecutionContext Record) and then later (after it's already been made the running execution context), it has a [[Generator]] field attached to it.

• The execution context stack could conceivably be modeled by giving each ExecutionContext Record something like a [[CallerContext]] field .

---

Downstream effects:
The HTML spec has some references to an execution context's "Realm component", which would be changed to its "[[Realm]] field" after this PR.

[bakkot]

Nice! I'll give this a more thorough review soon, but while I'm thinking of it:

The status quo creates the context and then separately sets each of its components. I kept that format, but you might prefer the use of a record "literal" to define it all in one step.

For now, I think we should stick with the existing format. I would like to address #2095 eventually, at which point I think it might make sense to switch to the literal syntax. But we'd need to find a way to express the CodeEvaluationState field clearly; it doesn't really have a "value" the same way other record fields would.

[jmdyck]

For now, I think we should stick with the existing format. I would like to address #2095 eventually, at which point I think it might make sense to switch to the literal syntax.

Yup.

But we'd need to find a way to express the CodeEvaluationState field clearly; it doesn't really have a "value" the same way other record fields would.

Yeah, I maybe should have raised that as another bullet. I mean, it's no less clear than in the status quo, but it does stick out more when we model things this way. The points where code evaluation state / [[CodeEvaluationState]] gets set are nowhere near the points where the context is created. This raises the question of what its status is between those points, and/or whether we should give it some nominal value at the point where the record is created.

[syg]

Where the status quo refers to the running execution context's SomethingOrOther, I introduced a step Let runningContext be the running execution context and then referred to runningContext.[[SomethingOrOther]]. You might prefer to introduce a compact way to say "the running execution context". (About the only precedent for this is the use of NewTarget in algorithms.)

In the memory model, the following step is often repeated:

1. Let execution be the [[CandidateExecution]] field of the surrounding agent's Agent Record.

Analogously here, how do you feel about

1. Let something be the [[Something]] field of the running execution context.

[jmdyck]

(force-pushed to resolve merge conflicts)

[jmdyck]

(force-pushed to rebase to master)

[jmdyck]

[...] how do you feel about

1. Let _something_ be the [[Something]] field of the running execution context.

I guess I'm okay with it.

[jmdyck]

(force-pushed to use the phrase "the [[Something]] field of the running execution context")

[michaelficarra]

@jmdyck This doesn't resolve #1742 on its own. There's also #2287, #2288, and the "ordered pair" in the Pattern Semantics section that I mentioned. Please remove (or rephrase) your reference to #1742 so we don't accidentally close it by merging this PR.

[bakkot]

@michaelficarra You should probably rename #1742 to make it clear it's tracking more stuff than its title currently claims.

[michaelficarra]

@bakkot Okay, changed it to match the project card.

[jmdyck]

force-pushed to:

• rebase to master
• clarify that this PR only resolves the first comment of issue replace complex spec values with spec records #1742

[jmdyck]

(force-pushed to resolve merge conflicts)

[jmdyck]

force-pushed to:

• rebase to master, resolve merge conflicts
• handle the new PrivateEnvironment component of ES Code Execution Contexts.

[jmdyck]

(force-pushed to rebase to master + resolve merge conflicts from #2408)

[jmdyck]

I introduced the term ExecutionContext Record, but left some occurrences of execution context. You might prefer to get rid of execution context entirely.

I would prefer that, yes.

Including occurrences in "running execution context" and "execution context stack"?

[michaelficarra]

@jmdyck no I think we can keep those terms

[jmdyck]

(force-pushed to resolve merge conflict)

[jmdyck]

(force-pushed to resolve merge conflicts)

[jmdyck]

(force-pushed to resolve merge conflicts)

[jmdyck]

(force-pushed to resolve merge conflicts)