Re: E patches for review: ELoader, Scope.with, seedVat

On May 20, 2010, at 11:15, Mark Miller wrote:

> On Thu, May 20, 2010 at 6:44 AM, Thomas Leonard <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected] 
> > wrote:
>
>> I'm thinking of adding EExpr.eval(ConstMap) too,
>> with the eventual goal of turning safeScope into a normal map. I  
>> think
>> someone (MarkM?) mentioned that E programs should see scopes as  
>> simple
>> 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  
> "EExpr.eval(ConstMap)",
> what about the fqnPrefix?

Three points:


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  
application.

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  
useful possibilities.


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  
>> map
>> 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  
>> makeTraceln,
>> 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  
makeTraceln?

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>