SES Compartment inconsistencies

[cmidgley]

I've found that Compartment isn't using the same interface in XS as the current Agoric version of ses. For example, this works on Node but fails on XS:

let test = 3;
const c = new Compartment({ test });
const r = c.evaluate("test");
if (r != 3) throw new Error("not 3");

Whereas this version works on XS but not Agoric's Node version (note the difference in the new Compartment options):

let test = 3;
const c = new Compartment({ globals: { test }  });
const r = c.evaluate("test");
if (r != 3) throw new Error("not 3");

Neither of these seem to match the Moddable documentation, if I understand it correctly. For example, the following, which is based on the documentation, does not work on XS:

globalThis.test = 3;
const c = new Compartment({ test: globalThis.test });
const r = c.evaluate("test");
// const r = c.evaluate("globalThis.test");  <-- this also does not work
if (r != 3) throw new Error("not 3");

What is the future for Compartment in XS? Is it planned to (eventually) be consistent with the Agoric implementation? I assume the documentation is just outdated and needs to be updated, but I'm also wondering if I may have some fundamental misunderstanding on how to use it.

I can work with this however it is implemented, but appreciate guidance on Moddable's plans and how to consume the interface correctly. It is challenging to figure out, due to the documentation inconsistencies and the lack of any TypeScript type definitions (the limited examples are the only source of accurate information, short of spending a lot of time in the source code).

By chance has anyone done any work on making TypeScript type definitions for the XS implementation of SES? That would make this much easier to figure out and consume.

[erights]

Attn @kriskowal

[erights]

What is the future for Compartment in XS? Is it planned to (eventually) be consistent with the Agoric implementation?

I'll let Peter, Patrick, and Kris speak to the specifics. But for this general question, the answer is definitely yes. The intention is for XS to fully implement what we expect to propose, whereas the ses-shim is a shim that may have some implementation limits compared to the expected proposal. But those implementation limits should eventually be the only differences.

[kriskowal]

The SES Compartment constructor is lagging and I hope to converge it with XS. To do that, we need a pattern where the first argument can be either endowments or options and distinguished in a way that both SES and XS would tolerate. I think the answer is to introduce a Symbol.for('options') symbol that can be used as a key in the first argument to indicate that it is being used as options and not endowments. This would eventually become unnecessary but remain harmless.

Portable code during the migration would look like:

const c = new Compartment({
  [Symbol.for('options')]: true,
  globals: { test },
  // &c
})

The other difference is the loadHook vs importHook, loadNowHook vs importNowHook. I think Moddable has agreed to alias the import* variety, so portable code would just use those.

I have work in flight that converges the module descriptor patterns. First part is in review endojs/endo#2321

[phoddie]

What is the future for Compartment in XS? Is it planned to (eventually) be consistent with the Agoric implementation?

The goal is for both implementations to be consistent with the proposed standard. As @kriskowal details, XS is generally ahead of the Agoric implementation on this. Both Moddable and Agoric are participating in the evolution of the proposal.

[cmidgley]

Thanks, everyone. For now, I've added a wrapper around Compartment for Node/SES for my code that implements the XS interface, so it will be easy later to remove it as appropriate.