-
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: Eliminate Lexical Environment #1697
Conversation
i'll try to get this tested in engine262 before the end of the week |
2c68ee5
to
3d4d88d
Compare
3d4d88d
to
e844ad1
Compare
I'm neutral on this change. Not everything that has a 1-to-1 relationship needs to be merged. It's also sometimes easier to not have bits you don't care about available to you. I'd prefer we get #1477 in and later make a decision about whether we do this. |
This sentence had me stumped for a while. Am I right in thinking that, in the context of this PR, "you" is an operation that deals with Environment Records, and the "bits you don't care about" is the 'outer environment reference' of the corresponding Lexical Environment? |
Correct! Sorry for the loose phrasing. |
I'm not so fond of getting rid of the term "lexical". It serves as a good reminder that JS uses lexical scoping, and that this data structure is the representation of that model. |
So then all the subtypes would add "Lexical"?
|
@jmdyck Oh, I completely forgot about that. Scrap the idea. An object environment record is definitely not lexical. At best, we could have the hierarchy
where the term "lexical" now replaced "declarative", for no good reason. |
https://tc39.es/ecma262/#sec-globalthis needs to be updated too |
With the change for globalThis, this patchset is passing test262 on engine262 :) |
Whoops, that snuck in on a rebase. Thanks for catching it. |
Added 2 commits:
Conceptually, these both fit in this PR's second commit ("Merge Lexical Environment into Environment Record"), but I kept them separate rather than squashing them in because I'm expecting all the commits will be squashed on merge anyway (if this PR is accepted). |
Added a commit to fix another change that snuck in on a rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The contents lgtm. At the end of the day I am also pretty neutral on the change. I'll bring it up at the next editor call to try to get a less tepid temperature.
…c39#1697) (currently attached to Lexical Environment, but that will change)
…ithms (tc39#1697) Mostly this amounts to erasing the distinction between _LE_ and "_LE_'s EnvironmentRecord". For the merged thing, I always used the metavariable/alias that had formerly been used for the Lexical Environment, even though this sometimes resulted in more diff lines.
…1697) ... mostly by changing "Lexical Environment" to "Environment Record". For lowercase "lexical environment", the treatment varies, because it's used with a few senses: - same as uppercase, - the LexicalEnvironment component of an execution context, and - the general (non-ES-specific) sense.
…ical Environments (tc39#1697)
…9#1697) (except for function Environment Record, which already has one)
bdd3771
to
0b988b7
Compare
@jmdyck apologies on not giving you the heads up you asked for; please feel free to make a quick followup for final touches |
It looks like nothing else snuck in on a rebase, but I did notice something minor that I should have changed, so I'll add that to #1965. |
... in FunctionDeclarationInstantiation, to balance the NOTE in the other arm of the if-else, and also for consistency with the NOTE at 27.a. (I should have done this in PR tc39#1697.)
... in FunctionDeclarationInstantiation, to balance the NOTE in the other arm of the if-else, and also for consistency with the NOTE at 27.a. (I should have done this in PR tc39#1697.)
... in FunctionDeclarationInstantiation, to balance the NOTE in the other arm of the if-else, and also for consistency with the NOTE at 27.a. (I should have done this in PR tc39#1697.)
Editorial: Reinstate an SDO rule PR tc39#1933 deleted SDO rules that are handled by the chain production rule, but it also deleted this one which isn't. (It has "TV" on the left and "TRV" on the right.) Editorial: Move an <emu-note> element PR tc39#1490 (among other things) moved the evaluation semantics for ArrowFunction from the Evaluation SDO to the NamedEvaluation SDO. The accompanying <emu-note> should have moved at the same time (in particular because of the reference to "step 3"). Editorial: Delete <emu-note> in TimeClip clause PR tc39#1827 (among other things) removed step 4 from the algorithm for TimeClip, obsoleting the accompanying emu-note that describes "the point of step 4". Conceivably, the note could be reworded to describe the effect of 'ToInteger' on step 3, but I don't think it'd be worth the bother. Editorial: Change "Step 2.a" to "Step 2.b" in RepeatMatcher note PR tc39#1889 (among other things) inserted a step before the former 2.a, but didn't update the note that referenced it. Editorial: Change step 7 to step 6 in SortCompare note Commit 9c1e076 (2015-10-26) introduced the '?' abbreviation for ReturnIfAbrupt. This caused the ToString call on step 7 to move to step 6, but the note that referred to it wasn't updated. Editorial: Fix typo: "Descritor" -> "Descriptor" Editorial: Fix typo: "GeneratorObject" -> "generator object" (There's no such thing as a GeneratorObject.) Editorial: Delete "as a parameter" after "is present" (It's the only place in the spec where we use that phrasing.) Editorial: Change "which" to "that" ... in "{String,Array,Map,Set} methods which return such iterators" Editorial: Insert a comma in SetDefaultGlobalBindings() Formerly, it read like "containing" modified "the property", when it actually modified "the property descriptor". Editorial: Change "lexical environment" to "Environment Record" ... in FunctionDeclarationInstantiation, to balance the NOTE in the other arm of the if-else, and also for consistency with the NOTE at 27.a. (I should have done this in PR tc39#1697.) Editorial: Change "step 3" to "step 4" in Note ... that accompanies the NamedEvaluation semantics for ArrowFunction : ArrowParameters `=>` ConciseBody PR tc39#1870 (among other things) inserted a step before the former step 3, but didn't update the note that referenced it.
See tc39/ecma262#1697. Also improve cross-references to |PipelineTopicBody|.
Formerly, 7.3 "The Window object" referred to `(realm).[[GlobalEnv]]'s EnvironmentRecord's [[GlobalThisValue]]` Here, `(realm).[[GlobalEnv]]` was a Lexical Environment, whose `EnvironmentRecord` component was a global Environment Record, with a `[[GlobalThisValue]]` field. However, tc39/ecma262#1697 eliminated Lexical Environments, merging them into Environment Records. So now `(realm).[[GlobalEnv]]` is a global Environment Record.
Formerly, 7.3 "The Window object" referred to `(realm).[[GlobalEnv]]'s EnvironmentRecord's [[GlobalThisValue]]` Here, `(realm).[[GlobalEnv]]` was a Lexical Environment, whose `EnvironmentRecord` component was a global Environment Record, with a `[[GlobalThisValue]]` field. However, tc39/ecma262#1697 eliminated Lexical Environments, merging them into Environment Records. So now `(realm).[[GlobalEnv]]` is a global Environment Record.
Formerly, 7.3 "The Window object" referred to `(realm).[[GlobalEnv]]'s EnvironmentRecord's [[GlobalThisValue]]` Here, `(realm).[[GlobalEnv]]` was a Lexical Environment, whose `EnvironmentRecord` component was a global Environment Record, with a `[[GlobalThisValue]]` field. However, tc39/ecma262#1697 eliminated Lexical Environments, merging them into Environment Records. So now `(realm).[[GlobalEnv]]` is a global Environment Record, and the reference should be `(realm).[[GlobalEnv]].[[GlobalThisValue]]`
See tc39/ecma262#1697 for context. Also adjust the style as per Web IDL.
See tc39/ecma262#1697 for context. Also adjust the style as per Web IDL.
See tc39/ecma262#1697 for context. Also adjust the style as per Web IDL.
... as suggested in PR #1473.
In effect, I've merged the concept/model of Lexical Environment into that of Environment Record. In my opinion, there's no point where the spec suffers from this merge. The only question is whether the improvement in the spec is worth the hassle of the transition.
The bulk of the change happens over the first 4 commits. Note that these commits are not logically separate -- the intermediate versions of the spec are not self-consistent. The only reason I separated them is to make it somewhat easier for someone who wants to check my work. You'd probably want to squash them when merging.
The last three commits are convenient add-ons.
Downstream effects:
X's EnvironmentRecord
to justX
.