Compartment transforms can't seem to add endowments

The failure I’m seeing in import-bundle (in https://github.com/Agoric/agoric-sdk/pull/762) seems to stem from Compartment` transforms not working the way I think they’re supposed to. The minimal test case is:

function transform(rewriterState) {
  const { src, endowments } = rewriterState;
  return { src: src.replace('replaceme', 'substitution'),
           endowments: { added: 'by transform', ...endowments },
         };
}

test.only('transforms can add endowments', t => {
  const src = '(function f4(a) {  return `replaceme ${added} ${a}`; })';
  const transforms = [transform];
  const c = new Compartment({}, {}, { transforms });
  const f4 = c.evaluate(src);
  const out = f4('ok');
  t.equal(out, 'substitution by transform ok');
  t.end();
});

I’ll add a branch with this appended to test/compartment.test.js for convenience.

What I’m seeing is that the c.evaluate fails with ReferenceError: added is not defined. When I read through compartment-shim.js, I thought each transform accepted a { src, endowments } object and returned a new one of the same shape, so my transform() ought to leave an added endowment that should show up by the time f4 is evaluated.

I also tried providing the transforms as an option to c.evaluate(src, { transforms }), but that didn’t work either.

[erights]

Since I’m familiar with the SES1 per-evaluation endowments mechanism, I could add such a thing to the SES-shim. However, it would be peculiar to the shim. We’ve already covered with Moddable that the XS SES machine will not support such a mechanism. Therefore we are also unlikely to propose such a mechanism.

Are the per-compartments endowments problematic because they are per-compartment, or because they’re on the global object? If the only problem is the latter, then we could get per-compartment global lexical endowments using the “optimizer” mechanism in the 8 magic lines. This also fits better with what Moddable can smoothly implement (attn @phoddie @patrick-soquet ). The shim would only support const bindings, but that’s all that what we need here. Yes?

I suspect tc39 would also be more tolerant to see a per-compartment global lexical environment added to the proposal, as a construction option, than to see one added as a per-evaluation option.

[michaelfig]

Are the per-compartments endowments problematic because they are per-compartment, or because they’re on the global object?

The latter. As long as the meter endowment is at least a const binding, it can only be referenced directly by name in an evaluation. That makes it possible for a transform to ensure that the evaluated pre-transformed code doesn’t reference it.