[e-lang] E patches for review: ELoader, Scope.with, seedVat
kpreid at switchb.org
Thu May 20 09:09:12 PDT 2010
On May 20, 2010, at 11:15, Mark Miller wrote:
> On Thu, May 20, 2010 at 6:44 AM, Thomas Leonard <tal at it-innovation.soton.ac.uk
> > wrote:
>> I'm thinking of adding EExpr.eval(ConstMap) too,
>> with the eventual goal of turning safeScope into a normal map. I
>> someone (MarkM?) mentioned that E programs should see scopes as
>> maps, rather than being given the low-level Scope object, which is an
>> implementation detail of the interpreter?
> This change by itself looks good. However, regarding
> what about the fqnPrefix?
1. Envs also have the distinction which prohibits binding a noun twice
within a single scope, and is controlled by nestOuter(). This is data
a ConstMap does not have.
2. Once guard-based auditing is implemented, there will be an
additional indirection ('bindings'), besides slots, between env and
their values. The virtue of the distinct Env (Scope) type is that it
provides operations which allow clients to ignore these additional
features (slots and bindings) when they are not relevant to the
Thomas, would you be interested in working on implementing guard-based
auditing in E-on-Java? It would then be straightforward to add the
DeepFrozen auditor for E code to E-on-Java, which enables a variety of
3. Also, EExpr.eval should go away, and be replaced with an explicit
reference to the evaluator -- because there may be multiple evaluators
for (a) eval with debugging access or other meta-level variations, and
(b) which vat the evaluation occurs in. Take a look at the stub
'__eval' binding which IIRC is currently in EoJ.
>> Finally, I'd like to add an extra argument to seedVat.run that is a
>> of additional bindings for the new vat's environment. This is so that
>> you can create a new vat with the same module configuration as the
>> current one, e.g.
>> seedVat(newVat, privSrc, <this>.getEnvExtras())
>> It uses the persistence sealer to serialize and unserialise the map,
>> which seems necessary because a loader has a reference to
>> which is unsafe. Is this the best way to do it?
> This seems plausible.
I think this is dangerous. The persistence amplification's particular
role is to serialize the state of a single vat; using it to send state
to another vat may result in duplicating state which really should be
specific to the origin vat.
Perhaps, instead of using the persistence sealer, use the unsafe
loader, which presumably can (ought to be able to, anyway) uncall
Kevin Reid <http://switchb.org/kpreid/>
More information about the e-lang