[e-lang] E patches for review: ELoader, seedVat

[Thomas Leonard]

On Thu, 2010-05-20 at 12:09 -0400, Kevin Reid wrote:
> 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  
> >> 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?

I guess it would have to be passed as an argument. It's only used to
provide a default for __getAllegedType, right? (a configured "traceln"
will already be in the environment, of course)

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

Is this useful when calling eval() from E?

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

That's possible. I think it needs to be a separate type, though:

- Scope: containing a ScopeLayout and an EvalContext with outers, fields
and locals) used internally.

- Env / ConstMap: no layout, just "outers".

But for simplicity I think I'd find it easier to understand if it was
just a map from names to slots (or bindings), even if I had to write a
little more code, e.g.

  code.eval(safeEnv | [ "answer" => makeFinalSlot(42) ])

I don't really like all the "if (k.startsWith("&"))" in Scope.java.

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

I'm a bit confused about DeepFrozen. For example, could this be
DeepFrozen?

def requireOne :DeepFrozen {
    to run(x) {
        require(x == 1)
    }
}

It seems not, because it mutates &require:

? (&require).isFinal()
# value: false
? requireOne(1)
? (&require).isFinal()
# value: true

Can any useful code be DeepFrozen?

I'm also confused about bindings. The wiki says what they are, but I
didn't understand why they're useful:

  http://wiki.erights.org/wiki/Guard-based_auditing

Is this so that auditors don't get free access to all the values? If so,
why not just subclass FinalSlot, e.g.

  class AuditableFinalSlot extends FinalSlot implements AuditableSlot

Then only give auditors auditable slots to look at (which would include
everything in safeScope)?

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

Makes sense.

> >> 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?

It can, but I don't want to let people get makeTraceln from <this>, e.g.
with:

def loader {
    to __optUncall() {
       return [makeLoader, "run", [sourceDir, envExtras, fqnPrefix]]
   }
}

You could recover makeLoader with:

  def makeLoader := <this>.__optUncall()[0]

You can then use makeLoader to create loaders that log with any fqname,
or uncall it to get makeTraceln. So, I think this needs to be sealed
somehow.


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk