[e-lang] Fixes wanted: Auditor exprs break object reconstruction and auditing

[Mark Miller]

On 10/2/06, Kevin Reid <kpreid at mac.com> wrote:
> The auditor expressions of an ObjectExpr are a very strange thing.
> They are part of the ObjectExpr, but, unlike every other part, are
> closed over by the resulting object, rather than being code executed
> later.

Yes, this does make them quite peculiar.


> Particularly, what should the intended support for pass-by-
> construction do with this case?
>
> ? def input := "aardvarks"
>  > def foo := Guard # or any other auditor
>  > def x := {
>  >   def x implements (def bar := foo; def foo := input; bar) {
> [...]
> As implemented, the values returned give the state of the object, but
> are not sufficient to reconstruct it since the auditor is not present.
>
> If "&foo" in the state map were to be the auditor instead, then part
> of the actual state of the object would be missing.

The behavior shown is what I'd intended, and it does have the problems
you point out.


> The only reasonable solution I've thought of so far is to consider
> the auditorExprs to be hidden, so that the object's script cannot use
> definitions from them; it will then be sufficient for meta.getState()
> to return the ObjectExpr's environment.
>
> I believe this will also simplify correct auditing.
>
> Please tell me what you think of this solution, and any alternatives
> you can think of.


I don't like my current behavior nor this suggestion, because neither
supports the following use-case. I propose that we seek a spec in
which an object can be pass-by-copy-by-mobile-code by doing something
as simple as the following:


def x implements ..., PassByCopy, ... {
    to __optUncall() {
        return [__eval, "run", [meta.context().getSource(), meta.getState()]]
    }
    ...
}

Note that this supposes several currently unimplemented changes:

* Moving the eval behavior from ENodes to a separate top-level function.
* Having meta.context().getSource() return what __eval expects for its
first argument, which
  should be changed from an ENode to a term-tree. (Not necessary for
the points made here,
  but I thought I'd note it.)
* Having meta.getState() return a Scope rather than just the name =>
slot mapping
  component of a Scope. This probably is necessary, depending on the
precise spec of
  evaluation.

In order for this to work reliably, we could specify that the
variables captured and reported by meta.getState() include those used
freely by the auditorExprs (therefore including PassByCopy), as well
as those used freely within the object itself. A draconian by simple
way to avoid the scope confusion issues you raise is to outlaw them:
We could say that none of the auditorExprs may shadow any variable
used freely by any previous occurrence in the same implements list.
Further, if necessary, we could say that the object itself may not use
freely any variable defined by any of the auditorExprs, and that
therefore meta.getState() must contain all the object's instance
variables.

An ObjectExpr which violates whatever constraints we decide on would
be statically rejected. This is consistent with our policy of being
willing to subject the programmer to somewhat surprising reasons for
static rejection, in order to ensure that any accepted code runs
unsurprisingly.

The object defined above, when serialized through Data-E, would
serialize the PassByCopy reference as an exit named "PassByCopy", to
be unserialized to the auditor named "PassByCopy" in the arrival
environment. This causes the object to acquire the corresponding
certification only if it passes the corresponding check, and otherwise
fail to unserialize. I believe this is precisely as it should be.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM