Re: Modifying safeScope?

On Mar 10, 2010, at 4:38, Thomas Leonard wrote:

> On 22 February 2010 14:35, Kevin Reid <[email protected]> wrote:
>> On Feb 22, 2010, at 9:19, Thomas Leonard wrote:
>>
>>> Another strange thing is that:
>>>
>>> ? interface SturdyRef {}
>>> java.lang.RuntimeException: Failed: can't redefine SturdyRef
>>>
>>> But I can override it using my loader. I think this is a good  
>>> thing (I
>>> want to run my unit-tests in an environment with fake SturdyRef
>>> objects
>>> that don't really use the network), but I'm wondering if there's  
>>> some
>>> security reason that means it shouldn't be redefined (auditors,  
>>> etc)?
>>
>> This is from the “unshadowable names” auditors plan. The idea was  
>> that
>> a certain set of nouns (all those in the safeScope) *always* have the
>> values they do, so auditors can rely on their behavior.
>>
>> This system has been superseded by the “guard-based auditing” plan,
>> which allows auditors to instead get a certain amount of information
>> about what nouns *are* bound to, but E-on-Java has not been updated  
>> to
>> acknowledge this.
>
> So, should I remove the calls to requireShadowable?

No, that's for the "already in scope" case, "def x := 1; def x := 2".  
Note the error message from it is not "can't redefine". That mechanism  
is fully controllable; see Scope#nestOuter/0.

A quick grep for "can't redefine" turns up elang.evm.NounPattern's  
constructor. I suggest stripping out the code there and everything  
else mentioning ScopeSetup.NonShadowable.

> It's already
> possible to create a scope with whatever bindings you like, e.g.
>
> ? e`true`.eval(safeScope.with("true", false))
> # value: false

Huh, I thought that wasn't possible. with/2 and withSlot/2 were added  
by MarkM in r278 on 2006-12-30, without mention in the commit log  
(boo); probably inspired by the same methods being provided in E-on-CL.

This change predates the final GBA design, but it may have (well,  
hopefully did) postdated the decision that unshadowable names was a  
bad idea.

> On the other hand, it would be nice to get an error by default if you
> try to redefine something because it's probably accidental ("def
> shadowing true := false" ?). I think that would be useful even for
> names that aren't in safeScope.
>
> Either way, it would also be nice to get an error in this case:
>
> ? def foo(x) {
>>  def x := 1
>>  return x
>> }
> # value: <foo>

I agree it would be nice to get an error there. That might violate  
some of the general scope principles since braces usually indicate a  
hide and also a shadowability boundary. MarkM?

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