Informal meeting notes from breakout session about Realms

[caridy]

Attendies: @dherman @erights @wycats @caridy

Notes

• The "Evaluator" concept to have a parametrized evaluator is eating up the Realm concept. It seems that we don't really need the two separate things.
• @wycats recommendation to simplify the API by simply allowing the creation of new realms that can be initialized with the intrinsics from other realm seems to be an important and desired simplification. This is very similar to the initial proposal of spawning realms, but it is now more formalized.
• We need more clarification between intrinsics and primordials, and codify that in the spec.
• We need more discussion around sloppy vs strict evaluation invocation from realm, @wycats feels that concatenating "use strict" might be sufficient, and desirable because of the implications of evaluating sloppy code in strict mode, and the possible frustration of users when code misbehaves when forced to run in strict mode.
• @erights is interested in exploring a little bit more the possibility of having an eval hook that can do the actual evaluation instead of just the program rewrite as it does today. It sounds like a very long shot though.

The formalization of the realm concept (tiling process from @dherman):

Realm's Configuration:

• intrinsics/primordials
• global object config
• import hook
• import.meta hook
• eval hook
• isDirectEval hook

Realm's Responsibilities:

• Evaluate script
• Evaluate Module

Realm's Features:

• evaluate script in strict mode or sloppy mode
• evaluate scripts are global script vs eval script

Examples

Some of the configuration

const r = new Realm({
  intrinsics: "inherit", // or maybe "parent"
  importHook: "inherit",
  importMetaHook: "inherit",
  evalHook: "inherit",
  isDirectEval: "inherit",
});

In the previous example, the Realm instance r is effectible a new scope since it will inherit all the hooks and all the intrinsics from the parent realm, but creates a new global object and a new this value, and allow evaluations bound to those values without introducing identity discontinuity, and delegating to the HOST behavior for import() calls.

Similarity, each of those configurations can be customized:

• if intrinsics is not specified, it will create a new set of intrinsics
• if importHook is not specified, it will throw on any import call. And if specified as a function, it will be used as the import hook as spec'd today.
• if evalHook is not specified, it will throw on any direct eval invocation. And if specified as a function, it will be used as the eval hook as spec'd today.
• if isDirectEval is not specified, it will run the default algo.

Open questions

• what should be the behavior if importMetaHook is not specified?
• can the global object value be proxified?
• can the this value be proxified?

[caridy]

Open questions

• [x] what should be the behavior if importMetaHook is not specified? Implement the basic wiring for now.
• [x] can the global object value be proxified? No (we need to gather more info about why not)
• [x] can the this value be proxified? Yes

[caridy]

adbf4b088b89c8aea1ed8f37e3d4dac604a7ec06 implements the intrinsics option and the "inherit" value for all hooks.

[erights]

"inherits" or not

Experience with the realms shim shows that piecemeal control of inherit-vs-make on individual issues is not a coherent start point. Rather, we need an explicit distinction between "root realms" vs "compartments" as some realm concepts must be per-root-realm and some must be per-compartment.

intrinsics

A terrible way to customize as cross realm leakage is too accident prone. A better starting mechanism is to run shim strings within each root realm on initialization, as the shim now does. This does leave the residual problem of endowments coming on from the defenseless feral world, which still needs good support for taming. See @ihab 's taming membrane at https://github.com/google/caja/tree/master/src/com/google/caja/apitaming .

importMetaHook

By the current design, realms does not deal directly with the issues of evaluating module code, but rather provides only a bridge to a separate module api. import.meta can only appear in module code. Thus, the importMetaHook should move from realms into this hypothetical but coupled module evaluation api.

evalHook

Should be renamed directEvalHook or something, so that it clearly applies only to direct eval. The current name caused much confusion. Also, the make should reflect that the hook is called to translate rather than to evaluate.

all are implementation limits for shim anyway

Just noting that none of these hooks can reasonably be implemented by the shim without an accurate parser, which would make the shim tremendously larger and more fragile. Rather, they should all be considered implementation limits of the shim as compared to the proposal. Nevertheless, without these, the shim is sufficient for most of the use cases that motivated the creations of the realms proposal.

[erights]

Missed:

importHook

Since this applies only to the import expression as evaluated in non-module code, it should have a name that is less confusing.

[caridy]

Most of the information here is about hooks, which are now features of the evaluator.