-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Editorial: Model execution context as a record #2246
base: main
Are you sure you want to change the base?
Conversation
Nice! I'll give this a more thorough review soon, but while I'm thinking of it:
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 |
Yup.
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 |
In the memory model, the following step is often repeated:
Analogously here, how do you feel about
|
85251e6
to
36f5402
Compare
(force-pushed to resolve merge conflicts) |
36f5402
to
1e28eeb
Compare
(force-pushed to rebase to master) |
I guess I'm okay with it. |
1e28eeb
to
2b46387
Compare
(force-pushed to use the phrase "the [[Something]] field of the running execution context") |
@michaelficarra You should probably rename #1742 to make it clear it's tracking more stuff than its title currently claims. |
@bakkot Okay, changed it to match the project card. |
2b46387
to
2843c22
Compare
force-pushed to:
|
2843c22
to
de3eb5a
Compare
(force-pushed to resolve merge conflicts) |
de3eb5a
to
0e8d49f
Compare
0e8d49f
to
8959226
Compare
force-pushed to:
|
3d0c24c
to
7a79833
Compare
9d9e403
to
9ae108b
Compare
9ae108b
to
076766e
Compare
076766e
to
847cc36
Compare
(force-pushed to rebase to master + resolve merge conflicts from #2408) |
847cc36
to
c02e1b4
Compare
2fe8a99
to
850156d
Compare
850156d
to
6e0ef3f
Compare
6e0ef3f
to
dd8bd1e
Compare
dd8bd1e
to
c5bfe97
Compare
c5bfe97
to
9d52d45
Compare
9d52d45
to
d78e496
Compare
2424321
to
0693eb6
Compare
(force-pushed to resolve merge conflicts) |
0693eb6
to
0cc704f
Compare
0cc704f
to
f882a94
Compare
(force-pushed to resolve merge conflicts) |
f882a94
to
d489f26
Compare
d489f26
to
792a368
Compare
11c8690
to
9d229e1
Compare
9d229e1
to
4029119
Compare
32fb60e
to
9e0477e
Compare
FYI https://github.com/tc39/ecma262/pull/3391/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR28625-R28630 introduces text that will have to be updated by this PR. |
000d66a
to
a83b586
Compare
Resolves the first comment in issue tc39#1742
…of ECMAScript code execution contexts
a83b586
to
8e2bd10
Compare
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 ofexecution context
. You might prefer to get rid ofexecution context
entirely.I changed the caption text of the three
Fields
tables, but not theirid
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 stepLet _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 ofNewTarget
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
andECMAScript code ExecutionContext Record
, but not forGenerator ExecutionContext Record
: it's difficult to see the latter as a subtype. AnExecutionContext Record
that represents the evaluation of a generator object is created as anECMAScript code ExecutionContext Record
(not aGenerator 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.