Editorial: Model execution context as a record by jmdyck · Pull Request #2246 · tc39/ecma262

jmdyck · 2020-12-08T06:31:39Z

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 · 2020-12-08T07:12:09Z

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 · 2020-12-08T18:52:22Z

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 · 2020-12-11T01:20:37Z

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:

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

Analogously here, how do you feel about

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

jmdyck · 2021-01-16T04:46:17Z

(force-pushed to resolve merge conflicts)

jmdyck · 2021-01-28T22:47:03Z

(force-pushed to rebase to master)

jmdyck · 2021-01-29T02:01:02Z

[...] 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 · 2021-01-29T02:01:39Z

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

michaelficarra · 2021-02-03T23:31:39Z

@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 · 2021-02-03T23:34:48Z

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

michaelficarra · 2021-02-04T00:29:38Z

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

jmdyck · 2021-02-05T01:33:17Z

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 · 2021-04-21T03:53:13Z

(force-pushed to resolve merge conflicts)

jmdyck · 2021-05-13T18:06:38Z

force-pushed to:

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

jmdyck · 2021-08-17T03:57:42Z

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

github-actions · 2025-10-01T02:55:25Z

The rendered spec for this PR is available at https://tc39.es/ecma262/pr/2246.

github-actions · 2025-11-05T19:36:39Z

The rendered spec for this PR is available at https://tc39.es/ecma262/pr/2246.

github-actions · 2026-03-11T18:40:44Z

The rendered spec for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

nicolo-ribaudo · 2026-04-16T15:02:29Z

+            [[CodeEvaluationState]]
+          </td>
+          <td>
+            implementation-specific


In a bunch of other places where we have fields whose contents are not managed by us (e.g. Module Record's [[HostDefined]]) we use "anything" instead.

Right, but we do actually manage code evaluation state to some extent: there are 3 steps where we set it.

Note that PR #2962 has a commit to make 'code evaluation state' less vague. (It doesn't update the type in this table, but it could.)

nicolo-ribaudo · 2026-04-16T16:24:04Z

-    <p>An execution context contains whatever implementation specific state is necessary to track the execution progress of its associated code. Each execution context has at least the state components listed in <emu-xref href="#table-state-components-for-all-execution-contexts"></emu-xref>.</p>
-    <emu-table id="table-state-components-for-all-execution-contexts" caption="State Components for All Execution Contexts" oldids="table-22">
+    <p>Each execution context is represented as an ExecutionContext Record, with at least the fields listed in <emu-xref href="#table-state-components-for-all-execution-contexts"></emu-xref>.</p>
+    <emu-table id="table-state-components-for-all-execution-contexts" caption="ExecutionContext Record Fields" oldids="table-22">


For the other editors: do you prefer to keep this table's id as-is, or change it to something like table-executioncontex-record-fields and moving the current ID to oldids?

I have a very slight preference for giving it an ID that is more similar to the other record definition tables, but I'm happy either way.

I don't think it matters.

nicolo-ribaudo · 2026-04-16T16:38:21Z

          1. Assert: _generator_.[[GeneratorState]] is ~suspended-start~.
          1. Let _genContext_ be the running execution context.
-          1. Set the Generator component of _genContext_ to _generator_.
+          1. Set _genContext_.[[Generator]] to _generator_.


(also in the async version)

What is happening here is that _genContext_ did not have yet a [[Generator]] field, and we are creating the extra field now effectively transforming the ExecutionContext Record into a Generator ExecutionContext Record?

If that's the case, I'd prefer either one of these options:

Add a note explaining what's happening. I don't think we dynamically add extra fields on existing records anywhere else?

Create a new Generator ExecutionContext Record here, copying all the other fields from the running execution context, and swap the running execution context record with this new one.

Give the [[Generator]] field to all execution contexts, and allow it to be ~empty~. <dfn> Generator ExecutionContext Record as "an ExecutionContext Record whose [[Generator]] field is not ~empty~".

Can an ExecutionContext Record be a Generator ExecutionContext Record withuot being an ECMAScript code ExecutionContext Record? (EDIT: The answer here is yes, when using CreateIteratorFromClosure. In principle I'd be fine with some sort of dyamond inheritance between these records and define an ECMAScript Code Generator ExecutionContext Record that implements both interfaces. We don't have methods on ExecutionContext Records anyway)

What is happening here is that _genContext_ did not have yet a [[Generator]] field, and we are creating the extra field now effectively transforming the ExecutionContext Record into a Generator ExecutionContext Record?

Yup, I think that's what's happening.

If that's the case, I'd prefer either one of these options:

Add a note explaining what's happening. I don't think we dynamically add extra fields on existing records anywhere else?

Well, there's ToPropertyDescriptor, which dynamically adds fields to a Property Descriptor record that was created with no fields. Moreover, some of those additions can change the 'type' of the PD from a generic PD to a data PD or an accessor PD. However, all of that is happening right after the record is created, so it kind of gets a pass. I think this is the only case where a component/field is created well after the thing/record is created (but I'm not positive).

Create a new Generator ExecutionContext Record here, copying all the other fields from the running execution context, and swap the running execution context record with this new one.

Note that the caption of this table is the only place that the spec mentions Generator Execution Contexts, so it doesn't seem to care about them as a type. (In places where it might ask "is this a Generator Execution Context?", it instead asks "does this have a Generator component?".)

Give the [[Generator]] field to all execution contexts, and allow it to be ~empty~. <dfn> Generator ExecutionContext Record as "an ExecutionContext Record whose [[Generator]] field is not ~empty~".

I'd be inclined to go with this one, but maybe not even bother mentioning "Generator ExecutionContext Record".

nicolo-ribaudo · 2026-04-16T16:45:51Z

@@ -50459,10 +50491,10 @@ <h1>
        <emu-alg>
          1. Let _genContext_ be the running execution context.
          1. Assert: _genContext_ is the execution context of a generator.


(also in the async version)

Can we have a more "mechanical" assertion? One of:

_genContext_.[[Function]] is a generator

_genContext_ is a Generator ExecutionContext Record

_genContext_ has a [[Generator]] field

The first one is probably too loose, as it does not always imply that there is a [[Generator]] field (e.g. while evaluating the default parameters of a generator function).

I'd go for 3, I think.

nicolo-ribaudo · 2026-04-16T16:49:08Z

+            an Object
          </td>
          <td>
            The Generator that this execution context is evaluating.


Not in this PR, but it'd be helpful to eventually <dfn> what a Generator is. Many people think of the generator as the function itself, rather than the object it returns.

nicolo-ribaudo · 2026-04-16T17:05:40Z

-              1. Set the ScriptOrModule of _moduleContext_ to _module_.
-              1. Set the VariableEnvironment of _moduleContext_ to _module_.[[Environment]].
-              1. Set the LexicalEnvironment of _moduleContext_ to _module_.[[Environment]].
+              1. Let _moduleContext_ be a new ECMAScript code ExecutionContext Record.


(this was already the same before, but while we are touching this code...) This should really be just an ExecutionContext Record. We are not evaluating JavaScript code in here.

I think you're right, but I'm not sure. If there's agreement, I can add a separate commit to that effect.

github-actions · 2026-04-28T22:30:18Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

github-actions · 2026-05-05T00:09:18Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

github-actions · 2026-05-07T01:49:50Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

github-actions · 2026-06-06T00:29:05Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

github-actions · 2026-06-16T13:25:29Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

jmdyck · 2026-06-16T13:26:46Z

Note that the "cleanup" section of #2962 is sort of a prerequisite for this PR, as it removes wording that treats execution context as anything other than a data structure. (Arguably, that cleanup should have been part of this PR instead of that one, but probably that won't matter much.)

github-actions · 2026-06-27T16:35:27Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

github-actions · 2026-08-10T01:01:23Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

Resolves the first comment in issue tc39#1742

github-actions · 2026-09-06T21:07:47Z

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/2246 and as multiple pages at https://tc39.es/ecma262/pr/2246/multipage .

jmdyck force-pushed the ExecutionContext_Record branch from 85251e6 to 36f5402 Compare January 16, 2021 04:44

jmdyck force-pushed the ExecutionContext_Record branch from 36f5402 to 1e28eeb Compare January 28, 2021 22:46

jmdyck force-pushed the ExecutionContext_Record branch from 1e28eeb to 2b46387 Compare January 29, 2021 02:01

jmdyck force-pushed the ExecutionContext_Record branch from 2b46387 to 2843c22 Compare February 5, 2021 01:31

jmdyck added the editorial change label Feb 5, 2021

jmdyck force-pushed the ExecutionContext_Record branch from 2843c22 to de3eb5a Compare April 21, 2021 03:52

jmdyck force-pushed the ExecutionContext_Record branch from de3eb5a to 0e8d49f Compare April 21, 2021 14:32

jmdyck force-pushed the ExecutionContext_Record branch from 0e8d49f to 8959226 Compare May 13, 2021 18:05

ljharb force-pushed the master branch 3 times, most recently from 3d0c24c to 7a79833 Compare June 29, 2021 02:21

jmdyck force-pushed the ExecutionContext_Record branch from 9d9e403 to 9ae108b Compare July 9, 2021 04:13

jmdyck marked this pull request as ready for review July 9, 2021 04:15

jmdyck force-pushed the ExecutionContext_Record branch from 9ae108b to 076766e Compare July 18, 2021 14:53

jmdyck force-pushed the ExecutionContext_Record branch from 076766e to 847cc36 Compare August 17, 2021 03:57

jmdyck force-pushed the ExecutionContext_Record branch from 847cc36 to c02e1b4 Compare August 17, 2021 03:58

jmdyck force-pushed the ExecutionContext_Record branch from 2d22f7d to 5b234c3 Compare August 29, 2025 19:56

jmdyck force-pushed the ExecutionContext_Record branch from 5b234c3 to ef79dbc Compare October 1, 2025 02:53

jmdyck force-pushed the ExecutionContext_Record branch from ef79dbc to 6859c77 Compare November 5, 2025 19:33

jmdyck force-pushed the ExecutionContext_Record branch from 6859c77 to 29234b3 Compare March 11, 2026 18:36

michaelficarra mentioned this pull request Apr 8, 2026

model object properties as records #3804

Open

nicolo-ribaudo requested changes Apr 16, 2026

View reviewed changes

jmdyck force-pushed the ExecutionContext_Record branch from 29234b3 to af3bb02 Compare April 28, 2026 22:05

jmdyck force-pushed the ExecutionContext_Record branch from af3bb02 to b73c3f7 Compare May 5, 2026 00:03

jmdyck force-pushed the ExecutionContext_Record branch from b73c3f7 to 72bb574 Compare May 7, 2026 01:44

jmdyck force-pushed the ExecutionContext_Record branch from 72bb574 to e1c4b5b Compare June 5, 2026 23:45

jmdyck force-pushed the ExecutionContext_Record branch from e1c4b5b to d33009b Compare June 16, 2026 13:15

jmdyck mentioned this pull request Jun 18, 2026

Layering: Revamp InitializeHostDefinedRealm #3728

Open

jmdyck force-pushed the ExecutionContext_Record branch from d33009b to 169ceb8 Compare June 27, 2026 16:28

jmdyck force-pushed the ExecutionContext_Record branch from 169ceb8 to c336c61 Compare August 10, 2026 00:53

jmdyck added 4 commits August 31, 2026 18:23

Editorial: Model execution context as a record

30f0506

Resolves the first comment in issue tc39#1742

fixup: Avoid saying "that execution context" by naming it

9ca3180

fixup: remove a line from esmeta-ignore.json

7ce3e7c

fixup: Wrap <dfn> around "ExecutionContext Record"

b6f6bba

Uh oh!

Conversation

jmdyck commented Dec 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bakkot commented Dec 8, 2020

Uh oh!

jmdyck commented Dec 8, 2020

Uh oh!

syg commented Dec 11, 2020

Uh oh!

jmdyck commented Jan 16, 2021

Uh oh!

jmdyck commented Jan 28, 2021

Uh oh!

jmdyck commented Jan 29, 2021

Uh oh!

jmdyck commented Jan 29, 2021

Uh oh!

michaelficarra commented Feb 3, 2021

Uh oh!

bakkot commented Feb 3, 2021

Uh oh!

michaelficarra commented Feb 4, 2021

Uh oh!

jmdyck commented Feb 5, 2021

Uh oh!

jmdyck commented Apr 21, 2021

Uh oh!

jmdyck commented May 13, 2021

Uh oh!

jmdyck commented Aug 17, 2021

Uh oh!

github-actions Bot commented Oct 1, 2025

Uh oh!

github-actions Bot commented Nov 5, 2025

Uh oh!

github-actions Bot commented Mar 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nicolo-ribaudo Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Apr 28, 2026

Uh oh!

github-actions Bot commented May 5, 2026

Uh oh!

github-actions Bot commented May 7, 2026

Uh oh!

github-actions Bot commented Jun 6, 2026

Uh oh!

github-actions Bot commented Jun 16, 2026

Uh oh!

jmdyck commented Jun 16, 2026

Uh oh!

github-actions Bot commented Jun 27, 2026

Uh oh!

github-actions Bot commented Aug 10, 2026

Uh oh!

jmdyck commented Dec 8, 2020 •

edited

Loading

nicolo-ribaudo Apr 16, 2026 •

edited

Loading