Re: Fwd: ScopeLayout hidden

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.

Essentially, the now-hidden operations *would* be package-private  
except that they're needed from more than one Java package.

> Does the taming affect Joe-E code?

No. Joe-E is entirely unrelated to E in implementation.

> If so, I guess this means that E's implementation can't be Joe-E,  
> since it wouldn't be able to do anything useful with Scope.

This is a good point.

> If not, it means that by default E code can't be allowed to call Joe- 
> E code (since it could pass safeScope to Java, creating the usual  
> confused deputy issues).

Isn't Joe-E's taming fully default-deny?

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

> The current version breaks my software (which is OK), but it would  
> be a shame if the only fix was to rewrite bits of it in Java.

Agreed that Java code should not be necessary. Use the eval technique  
I mentioned previously to construct Scopes (environments).

In E-on-CL, Scopes have methods like 'with/2' to augment them without  
eval; this concept should be reviewed for good design and possibly  
added to E-on-Java.

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