feat(ses): Support global lexicals

[kriskowal]

As distinct from endowments, extra properties of globalThis, global lexicals are constant free variables that are not reachable by computing properties of globalThis.

[warner]

Looks good to me, but it'd be nice to have those extra tests. And maybe have @erights take a look at the evaluator changes just in case.

[warner]

The purpose of this check is to keep the name from showing up in the constants list twice, right? (if the caller provided the same name for both a global and a lexical?) The way this is written made me think that maybe we're enforcing some important security property.

Not recommending a change that's outside the scope of this PR, but at some point would it be better (or maybe worse..) to just collect all these names into a Set?

[warner]

yeah, do we not need this protection in this one case because we created globalLexicals ourselves, and know that it doesn't contain any accessors? I'm happy to retain the reflectGet for safety, but we might amend the comment if we know that's why we're doing it, and point out the difference between globalLexicals (which we create, and is static) and endowments (which.. might come from the user, and might have accessors, which we're happy to let execute, but not let those accessors use our this object?)

[warner]

Also, just confirming my understanding.. when we say "endowments", do we strictly mean properties of globalThis? I know we needed a term for "global lexicals" to make it clear that they're distinct from (enumerable, unavoidably reachable through computed property lookup) properties of the global. But I'm wondering what our historical definition has been (maybe this is a question for @erights).

Before we needed this distinction for SES, did we use "endowments" as a more generic term to encompass names that were visible in the global scope, without much consideration as to whether they could or could not be denied to code through static analysis and rejection of matching free-variable names? Did E have any notion of globalThis, or is this distinction a new requirement, driven by JS having a name for the collection of global names?

[michaelfig]

Also, just confirming my understanding.. when we say "endowments", do we strictly mean properties of globalThis? I know we needed a term for "global lexicals" to make it clear that they're distinct from (enumerable, unavoidably reachable through computed property lookup) properties of the global. But I'm wondering what our historical definition has been (maybe this is a question for @erights).

I can fill in some of this. "endowments" used to be "global lexicals" in SES-0.6. It was when Moddable created the Compartment API that they made "endowments" a synonym for "globalThis properties". We then adopted this meaning, which necessitated introducing "global lexicals" as a new categorisation for what we had before.

[erights]

Also, I didn't see anything about the constants optimization in this PR. Did I miss it, or does this PR no longer mess with that?

[kriskowal]

Also, I didn't see anything about the constants optimization in this PR. Did I miss it, or does this PR no longer mess with that?

The constants optimization no longer requires changes. The optimization still occurs by virtue of the compartment endowments, compartment global lexicals, and module live bindings all coëxisting on the localObject (as it’s named in the scope handler) or endowments (as it’s named by the evaluator).

Endowment has indeed become a very confusing name internally. There are things named endowment throughout the evaluator machinery that do not correspond to the compartment constructor option. I would like to straighten those out in this change.

[erights]

I no longer understand how things are wired up. I need you to walk me through this verbally while I ask questions. Tomorrow (Friday) afternoon?

[kriskowal]

I’ve tacked on a few incremental commits.

I’ve moved back to tape @ 4. This version doesn’t have a match method, but we probably shouldn’t be validating error messages anyway, especially to the extent I had, which may have made the tests brittle between engines.

Copying globalLexicals and per-evaluate endowments by property descriptors turned out to be necessary. The per-evaluate endowments are mutable, per the existing tests, and global lexicals are not. The localObject for modules also needs to copy by property descriptor because the globalLexicals are also frozen there, because they are required to be immutable, but localObject must remain extensible until all of the live binding traps are defined.

[erights]

LGTM!