Rename "Environment Record" as "Scope Record", and recast Lexical Environment as a Record #1477

jmdyck · 2019-03-13T04:24:27Z

(Follow-up to issue #1473.)

In a comment in issue #1473, @allenwb said:

This distinction [between Lexical Environments and Environment Records] might have been clearer if I had used the term "Bindings Record" in place of "Environment Record".

I agree that a renaming would help, but I wasn't happy with "Bindings Record" for a couple of reasons. For one thing, "Bindings" is plural, which smells off to me. For another, if we ever fully specify declarative Environment/Scope Records, we'll probably define a [[Bindings]] field, and having "Bindings" on both the outside and the inside might be confusing.

I considered terms like "contour" and "nest", but then I noticed that, in the current spec, Environment Records are almost always defined as representing (or being associated with) a scope:

"An Environment Record records the identifier bindings that are created within the scope of its associated Lexical Environment."
"Each declarative Environment Record is associated with an ECMAScript program scope ..."
"A function Environment Record is a declarative Environment Record that is used to represent the top-level scope of a function ..."
"A global Environment Record is used to represent the outer most scope ..."
"A module Environment Record is a declarative Environment Record that is used to represent the outer scope of an ECMAScript Module."

So it seems to me that renaming "Environment Record" to "Scope Record" is a reasonably good fit.

This PR starts by renaming metavariables that currently involve the word "scope". (These all refer to Lexical Environments.)

I've split the PR into 10 commits, each of which has a set of fairly similar changes, for those who want to review it that way. Whether it stays that way on merging is up to the editors, although I'd suggest leaving at least the last commit ("Recast Lexical Environment as a Record") separate, since it's logically independent.

Effects on downstream dependencies:

HTML: nothing that I could see.
WebIDL: one reference to "object environment record", which I think is referring to the ES concept (although the "Terms defined by reference" section doesn't mention it).

gibson042 · 2019-03-13T17:47:49Z

spec.html

-    <p>A <dfn id="global-environment">global environment</dfn> is a Lexical Environment which does not have an outer environment. The global environment's outer environment reference is *null*. A global environment's EnvironmentRecord may be prepopulated with identifier bindings and includes an associated global object whose properties provide some of the global environment's identifier bindings. As ECMAScript code is executed, additional properties may be added to the global object and the initial properties may be modified.</p>
+    <p>A <dfn>Lexical Environment</dfn> is a specification type used to define the association of |Identifier|s to specific variables and functions based upon the lexical nesting structure of ECMAScript code. Usually a Lexical Environment is associated with some specific syntactic structure of ECMAScript code such as a |FunctionDeclaration|, a |BlockStatement|, or a |Catch| clause of a |TryStatement| and a new Lexical Environment is created each time such code is evaluated.</p>
+    <p>A Lexical Environment is represented as a Record with two fields: [[ScopeRecord]] and [[OuterEnv]]. The [[ScopeRecord]] field is a Scope Record, which records the identifier bindings that are created within the scope of its associated Lexical Environment. The [[OuterEnv]] field is either null, or a reference to an outer Lexical Environment. This reference is used to model the logical nesting of Lexical Environment values. The outer reference of a (inner) Lexical Environment is a reference to the Lexical Environment that logically surrounds the inner Lexical Environment. An outer Lexical Environment may, of course, have its own outer Lexical Environment. A Lexical Environment may serve as the outer environment for multiple inner Lexical Environments. For example, if a |FunctionDeclaration| contains two nested |FunctionDeclaration|s then the Lexical Environments of each of the nested functions will have as their outer Lexical Environment the Lexical Environment of the current evaluation of the surrounding function.</p>
+    <p>A <dfn id="global-environment">global environment</dfn> is a Lexical Environment which does not have an outer environment. The global environment's outer environment reference is *null*. A global environment's [[ScopeRecord]] may be prepopulated with identifier bindings and includes an associated global object whose properties provide some of the global environment's identifier bindings. As ECMAScript code is executed, additional properties may be added to the global object and the initial properties may be modified.</p>


Should "outer environment reference" here be "[[OuterEnv]]"?

At outer environment reference is *null* ? Yes, it should.

(Can you do that as a Github 'suggestion'? I want to see how they look from this side.)

Suggested change

<p>A <dfn id="global-environment">global environment</dfn> is a Lexical Environment which does not have an outer environment. The global environment's outer environment reference is *null*. A global environment's [[ScopeRecord]] may be prepopulated with identifier bindings and includes an associated global object whose properties provide some of the global environment's identifier bindings. As ECMAScript code is executed, additional properties may be added to the global object and the initial properties may be modified.</p>

<p>A <dfn id="global-environment">global environment</dfn> is a Lexical Environment which does not have an outer environment. The global environment's [[OuterEnv]] field is *null*. A global environment's [[ScopeRecord]] may be prepopulated with identifier bindings and includes an associated global object whose properties provide some of the global environment's identifier bindings. As ECMAScript code is executed, additional properties may be added to the global object and the initial properties may be modified.</p>

Thanks. (GitHub isn't letting me commit the suggestion from here, so I'll do it the normal way.)

allenwb · 2019-03-13T19:22:22Z

So it seems to me that renaming "Environment Record" to "Scope Record" is a reasonably good fit.

The problem I see with that name is that the terms "environment" and "scope" are both informally used by various language implementors often for the same or very similar concepts. So having an "Environment Record" that contain (via reference or directly) a "Scope" record may be as confusing (to some readers) as what we already have.

The distinction that I think is important is the distinction between how the identifiers introduced within a specific scope/environment map(binds) to storage/values and how that specific scope/environment relates to other scopes/environments that have binding for some of the same identifiers.

I agree that the pluralness of "Binds Record" is awkward for some reason and I originally considered suggesting "Binding Record" but that isn't really right because we are talking about an abstraction that captures multiple bindings. I think some of the linguistic awkwardness comes form the word "record". Alternative names that avoid "record" seem to scan better without stumbling over singular/plural confusion: "binding map", "binding store", "binding table", etc.

It is also worth remembering that "Environment Records" are not just simple record abstractions. They are an object-like specification abstraction that implicitly dispatch a set of polymorphic specification operations depending upon the specific kind of Environment Record. So not having "record" in the name may also be good for that reason.

So, I suggest using the two terms "Environment" and "BindingTable".

An Environment has a [[Bindings]] fields that contains/references a BindingTable. But because of the polymorphic nature of Binding Tables I wouldn't expect any of them to ever have a [[Bindings] field. A Declarative Binding Table (if its specification was made more concrete, which I don't think is really necessary) might have a [[BindingMap]] field whose value is a map, an Object Binding Table would have a [[BindingObject]] field, a Global Binding Table could retain the the current [[ObjectRecord]] and [[DeclarativeRecord]] or slightly rename them (but, ugh more churn).

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

littledan · 2019-03-19T10:49:15Z

I think it's nice if such refactorings/renamings help reduce complexity. I'd be in favor of the originally proposed reduction in indirection.

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck · 2019-06-17T21:18:01Z

(force-pushed to resolve merge conflicts)

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck · 2019-07-19T02:58:19Z

(force-pushed to resolve merge conflicts again)

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck · 2019-09-14T17:05:10Z

(force-pushed to resolve merge conflicts /3)

syg · 2019-09-14T18:11:13Z

I'd rather not we rename Environment to Scope for precisely the reasons @allenwb stated. Scopes are used in at least SpiderMonkey and V8 to denote static, parse-time concepts.

jmdyck · 2019-09-14T19:51:37Z

Scopes are used in at least SpiderMonkey and V8 to denote static, parse-time concepts.

In that case, what terms do they use to denote what the spec models as Environment Records? And, since I'm in the neighborhood, do they make a distinction between what the spec models as Environment Records and Lexical Environments? (Asking for a friend #1473.)

syg · 2019-09-17T00:49:12Z

In that case, what terms do they use to denote what the spec models as Environment Records?

Just a quick caveat: the data structures that engines heap allocate to hold bindings during runtime for closures aren't exactly Environment Records, since the engines will only keep the bindings that are in-fact closed over. If a function's bindings can be all stack allocated, there will be no runtime component.

SpiderMonkey calls them environments or environment objects after the spec.

V8 calls them Contexts, though V8's notion of Context is broader, I think.

And, since I'm in the neighborhood, do they make a distinction between what the spec models as Environment Records and Lexical Environments? (Asking for a friend #1473.)

No, they don't and probably never will. Having 2 allocations would be very wasteful.

jmdyck · 2019-09-17T02:03:53Z

Cool, thanks. So from that point of view, PR #1697 is probably preferable to this.

syg · 2019-09-17T18:34:36Z

Yeah, #1697 seems fine to me.

allenwb · 2019-09-18T17:18:41Z

I stand by my suggestion in #1477 (comment)

So, I suggest using the two terms "Environment" and "BindingTable".

And still contend that the conceptual merging done in #1697 is undesirable.

since I'm in the neighborhood, do they make a distinction between what the spec models as Environment Records and Lexical Environments?

It is irrelevant whether or not any implementation would actually use distinct data structure to represent the nesting of scopes and the scope-local bindings of identifiers. It is not the purpose of this kind of language specification to provide design suggestions for implementor (that's the job of the compiler design literature). The purpose is the specification is to clearly described the requirement semantics so that an implementor can verify that their preferred (and likely optimized) design will conform to the requirements of the specification.

It is very unlikely that an actual implementation would follow either the model has been used in the specification since ES5 or the model in #1697. There is a rich literature (and real world experience) regarding how to implement and optimize lexical scoping and closure capture. That's what a serious ES implementation would build upon and then check against the simple model used in the specification.

jmdyck · 2019-09-18T20:40:26Z

It is not the purpose of this kind of language specification to provide design suggestions for implementor [...]. The purpose is the specification is to clearly described the requirement semantics so that an implementor can verify that their preferred (and likely optimized) design will conform to the requirements of the specification.

I agree. However, where correspondences exist between the spec and its implementations, and where there is some agreement among implementers how to name things, then I think it's helpful if the spec doesn't use conflicting names. So I respect @syg's comments about the use of the terms "scope" and "environment" in implementations.

Similarly, if implementations do have separate constructs/concepts for what the spec terms Lexical Environment and Environment Record, I'm interested in whether there's any consensus on how they're named.

(Of course, it's not just implementers who have terminology for these kinds of concepts/constructs. There's also the terminology used in the theory and teaching of programming languages. But around here, it's generally easier to get feedback from implementers than from theorists and educators.)

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck · 2019-10-14T15:58:33Z

(force-pushed to resolve merge conflicts /4)

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck · 2019-10-24T01:28:11Z

(force-pushed to resolve merge conflicts /5)

... when it's passed to NewFooEnvironment() as the outer lexical environment.

... because they're all Lexical Environments.

michaelficarra · 2019-10-24T23:27:59Z

IMO, it'd be appropriate to tackle #1741 in this PR as well. @jmdyck do you have interest in doing that?

jmdyck · 2019-10-25T00:49:18Z

I'm interested in tackling #1741, but I think:

it wouldn't be appropriate to add that to this PR, and
we should first get an editorial decision on this PR vs Editorial: Eliminate Lexical Environment #1697 vs neither (vs conceivably a combination of both, but probably not).

michaelficarra · 2019-10-25T00:59:00Z

spec.html

                    1. Append _F_ to _declaredFunctionOrVarNames_.
                  1. When the |FunctionDeclaration| _f_ is evaluated, perform the following steps in place of the |FunctionDeclaration| Evaluation algorithm provided in <emu-xref href="#sec-function-definitions-runtime-semantics-evaluation"></emu-xref>:
                    1. Let _genv_ be the running execution context's VariableEnvironment.
-                    1. Let _genvRec_ be _genv_'s EnvironmentRecord.
+                    1. Let _gScope_ be _genv_.[[ScopeRecord]].


I know this is supposed to be a fairly mechanical renaming, but I don't really like how the names used in this one algorithm stand out. Can we make them slightly more descriptive?

Yeah, the names were kind of odd to begin with, and the mechanical renaming didn't improve things. I'd suggest:

_genv_ -> _evalVarEnv_

_benv_ -> _evalLexEnv_

_gScope_ -> _evalVarScope_

_bScope_ -> _evalLexScope_

(And similarly in the previous clause, for consistency.)

michaelficarra

You've missed an EnvironmentRecord reference in 8.1.1 globalThis (probably due to its introduction since opening this PR). Other than that, LGTM.

(the Lexical Environment component)

... and [[DeclarativeRecord]] as [[DeclarativeScope]]. (fields of the Global Scope Record)

(internal slot of ArgGetter/ArgSetter function)

(Mostly rename "_envRec_" to "_scope_", but various others.)

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck · 2019-10-25T01:40:40Z

You've missed an EnvironmentRecord reference in 8.1.1 globalThis (probably due to its introduction since opening this PR).

Yeah, that would have snuck in as a "non-conflicting" merge. Thanks for catching it. Fixed!

syg · 2019-10-25T02:04:52Z

I am not in favor of this renaming. It's a lot of churn for no added clarity (and possibly confusion for people already used to the existing terminology).

To existing implementers used to reading the spec to implement scope/environment-related things, they're already tuned in to how 262 uses "Environment", including "Environment Record". To new implementers, the meaning of "Scope" in "Scope Record" doesn't exactly correspond to static notions of scoping.

michaelficarra · 2019-10-25T18:04:42Z

@syg I think the renaming is a significant enough readability benefit for the new reader, and will not invalidate the familiarity that experienced users have acquired.

the meaning of "Scope" in "Scope Record" doesn't exactly correspond to static notions of scoping

How so?

syg · 2019-10-25T18:55:25Z

I think the opposite about invalidating the familiarity.

As for why I think "Scope Record" is not a good name, it comes down to "scoping" meaning the visibility of bindings, which is a static property on the source text.

In something like function outer() { let x = 0; return function inner() { x++; } }, the scope of the x binding is the body of outer, regardless of how many times outer gets invoked or how many inner closures are made. Scoping doesn't say anything about "placement" of bindings: where they should live (on a LIFO short-lived thing like a stack or on a long-lived thing like an environment?), how they should be represented during evaluation. Environment Records are the spec mechanism of that placement: they're tables of bindings, get made anew per-closure, etc. One could argue that they are evaluation-time reifications of scope, but they're more, they reify both scope + placement, and I think Environment is a fine name for that.

allenwb · 2019-10-26T16:55:23Z

@syg

As for why I think "Scope Record" is not a good name, it comes down to "scoping" meaning the visibility of bindings, which is a static property on the source text.

I totally agree with Shu. "Scope Record" is a terrible name and this usage is contrary to the common use in programming language design/implementation literature. The data structures bind "names" to entities are generally known as "environments". Environment Record is a fine name for a concrete realization of that concept.

Consider, for example, what is currently called a "Global Environment Record". It encapsulates and a Declarative Environment Record and an Object Environment Record. Those encapsulated records correspond to different binding mechanism not to different parts of the source code. Yet renaming them to as "x Scope Records" would strongly suggest exactly the latter.

allenwb · 2019-10-26T16:56:45Z

Environment Record is a fine name for a concrete realization of that concept.

But "Bindings Record" would be even a better name.

syg · 2019-10-31T18:39:41Z

@jmdyck We discussed this in the editor call and decided to keep the current Environment name as is, for the same reasons @allenwb and myself have expressed. Thank you for all your tireless editorial work.

jmdyck · 2019-10-31T19:27:53Z

Okay. Did you discuss @allenwb's suggestion of "Bindings Record"?

syg · 2019-10-31T20:38:18Z

Okay. Did you discuss @allenwb's suggestion of "Bindings Record"?

Briefly. The conclusion was the improvement of "Bindings Record" over "Environment" isn't worth the amount of churn in the spec.

bakkot · 2019-10-31T20:39:21Z

The "recast Lexical Environment as a Record" part of this PR still seems valuable; @jmdyck would you be willing to open it as a separate PR? I can do so if you'd prefer.

jmdyck · 2019-11-01T13:26:14Z

The "recast Lexical Environment as a Record" part of this PR still seems valuable

Yeah, I was thinking that myself, but it might as well wait until there's a decision on PR #1697.

gibson042 reviewed Mar 13, 2019

View reviewed changes

ljharb added the editorial change label Mar 14, 2019

jmdyck force-pushed the scope-records branch from 9ba0156 to da8326c Compare March 18, 2019 16:26

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Mar 18, 2019

Editorial: Recast Lexical Environment as a Record

da8326c

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck force-pushed the scope-records branch from da8326c to 0e32f07 Compare June 17, 2019 21:17

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Jun 17, 2019

Editorial: Recast Lexical Environment as a Record

0e32f07

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck force-pushed the scope-records branch from 0e32f07 to f6568d3 Compare July 19, 2019 02:57

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Jul 19, 2019

Editorial: Recast Lexical Environment as a Record

f6568d3

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Sep 14, 2019

Editorial: Recast Lexical Environment as a Record

13a9c9d

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck force-pushed the scope-records branch from f6568d3 to 13a9c9d Compare September 14, 2019 17:03

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Oct 14, 2019

Editorial: Recast Lexical Environment as a Record

a459724

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck force-pushed the scope-records branch from 13a9c9d to a459724 Compare October 14, 2019 15:57

jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Oct 24, 2019

Editorial: Recast Lexical Environment as a Record

1c27823

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck force-pushed the scope-records branch from a459724 to 1c27823 Compare October 24, 2019 01:27

jmdyck added 2 commits October 24, 2019 15:53

Editorial: Rename _scope_ -> _outer_

308d73e

... when it's passed to NewFooEnvironment() as the outer lexical environment.

Editorial: Rename _scope_ (and _Scope_) to _env_

938863b

... because they're all Lexical Environments.

ljharb requested review from syg, michaelficarra, allenwb, bakkot and a team October 24, 2019 22:02

michaelficarra reviewed Oct 25, 2019

View reviewed changes

michaelficarra approved these changes Oct 25, 2019

View reviewed changes

michaelficarra mentioned this pull request Oct 25, 2019

Editorial: Eliminate Lexical Environment #1697

Merged

jmdyck added 6 commits October 24, 2019 21:36

Editorial: Rename "EnvironmentRecord" as "ScopeRecord"

f7fa5f3

(the Lexical Environment component)

Editorial: Rename GetThisEnvironment() as GetThisScope()

bf50e92

Editorial: Rename [[ObjectRecord]] as [[ObjectScope]]

866310c

... and [[DeclarativeRecord]] as [[DeclarativeScope]]. (fields of the Global Scope Record)

Editorial: Rename [[Env]] as [[Scope]]

3df11f0

(internal slot of ArgGetter/ArgSetter function)

Editorial: Rename metavariables for Scope Records

6a77dea

(Mostly rename "_envRec_" to "_scope_", but various others.)

Editorial: Recast Lexical Environment as a Record

0d49f8a

Includes suggestion from gibson042 (tc39#1477 (comment)) to change another occurrence of "outer environment reference" to "[[OuterEnv]] field".

jmdyck force-pushed the scope-records branch from a410483 to 0d49f8a Compare October 25, 2019 01:40

syg closed this Oct 31, 2019

jmdyck deleted the scope-records branch March 1, 2021 14:26

Rename "Environment Record" as "Scope Record", and recast Lexical Environment as a Record #1477

Rename "Environment Record" as "Scope Record", and recast Lexical Environment as a Record #1477

Conversation

jmdyck commented Mar 13, 2019

gibson042 Mar 13, 2019

Choose a reason for hiding this comment

jmdyck Mar 13, 2019

Choose a reason for hiding this comment

gibson042 Mar 14, 2019

Choose a reason for hiding this comment

jmdyck Mar 18, 2019

Choose a reason for hiding this comment

allenwb commented Mar 13, 2019

littledan commented Mar 19, 2019

jmdyck commented Jun 17, 2019

jmdyck commented Jul 19, 2019

jmdyck commented Sep 14, 2019

syg commented Sep 14, 2019

jmdyck commented Sep 14, 2019

syg commented Sep 17, 2019

jmdyck commented Sep 17, 2019

syg commented Sep 17, 2019

allenwb commented Sep 18, 2019

jmdyck commented Sep 18, 2019

jmdyck commented Oct 14, 2019

jmdyck commented Oct 24, 2019

michaelficarra commented Oct 24, 2019

jmdyck commented Oct 25, 2019

michaelficarra Oct 25, 2019

Choose a reason for hiding this comment

jmdyck Oct 25, 2019

Choose a reason for hiding this comment

michaelficarra Oct 25, 2019

Choose a reason for hiding this comment

michaelficarra left a comment

Choose a reason for hiding this comment

jmdyck commented Oct 25, 2019

syg commented Oct 25, 2019

michaelficarra commented Oct 25, 2019

syg commented Oct 25, 2019

allenwb commented Oct 26, 2019

allenwb commented Oct 26, 2019

syg commented Oct 31, 2019

jmdyck commented Oct 31, 2019

syg commented Oct 31, 2019

bakkot commented Oct 31, 2019

jmdyck commented Nov 1, 2019