Re: Fwd: ScopeLayout hidden

On Mon, 2010-03-01 at 06:45 -0500, Kevin Reid wrote:
> On Mar 1, 2010, at 4:49, Thomas Leonard wrote:
> >
> >> From: Mark Miller <[email protected]>
> >> Date: February 27, 2010 18:06:46 EST
> >>
> >> Kevin, Besides the obvious change, this [patch] also does a bit of   
> >> comment reformatting. And it adds maximally restrictive safej files  
> >> forScopeLayout and EvalContext, just in case they leak by other  
> >> means. See ENode#getScopeLayout() as such a leak that should  
> >> probably be plugged more directly than just making ScopeLayouts  
> >> opaque.
> ...
> > But I find the solution quite surprising. I thought taming was only  
> > needed for legacy code, not for clean ocaps code such as E itself.
> 
> I generally agree; this is a bit of unusual case. While we were  
> discussing this, MarkM told me that the original intent was that Scope  
> (environment) objects were *entirely* opaque (i.e. E code can only  
> pass them around); I objected pointing out that withPrefix, nestOuter,  
> etc. were often useful to application code.

It would be interesting to know where E code uses Scope objects and why.

So far, the only place I've passed safeScope as an argument has been
when evaluating code, e.g.

  code.eval(safeScope)

So, the problem here is that the scope allows itself to be modified by
"code" in ways that the E code holding it can't do.

What if emakers got given only a facet on safeScope that allowed
creation of new (underlying) scopes, containing a copy of the execution
environment? Then you could do:

  code.eval(safeScopeFacet.newScope())

Are there any places where E code needs to pass safeScope to something
that should operate on the underlying scope, rather than on a copy?

Does anything assume that scopes will only ever be modified in certain
ways, which aren't enforced?

[...]

> > I was expecting that Scope would be split into two objects, with the  
> > underlying one used by the EVM internally and a limited facet given  
> > to E code as "safeScope". Then E code could freely created new  
> > scopes and interact with the interpreter just as Java code can  
> > (using the underlying Scope object), but without giving E code this  
> > access by default through safeScope.
> 
> If I understand correctly, the operations hidden are in fact used  
> whenever you eval using a given Scope (environment), so facets don't  
> apply here. This is more like how SturdyRefs don't reveal their crypto  
> bits except to the comm system.

I see it could work, but the design just makes me nervous. I see the
SturdyRef code links to a (fixed) bug "SturdyRefs amplify even when they
should not", although the link doesn't work so I'm not sure what the
issue was.


-- 
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-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk