Re: Bindings and guard-based auditing

On Wed, 2010-05-26 at 00:39 -0400, Kevin Reid wrote:
> On May 25, 2010, at 14:42, Thomas Leonard wrote:
[...]
> > By the way, I'm assuming we'll just audit everything for DeepFrozen
> > automatically whenever possible, or my fingers will get very tired
> > from typing "implements DeepFrozen" everywhere.
> 
> No. This would form an unavoidable one-bit implementation information  
> leak. Feel free to suggest syntax and naming changes to reduce the  
> verbosity. (You can always 'def &&DF := &&DeepFrozen', of course.)

How can I write a function then?

def add(x, y) { return x + y }

becomes

def add as DeepFrozen {
	to run(x, y) { return x + y }
}

Why would leaking that something isn't DeepFrozen be a problem?

> (Random thought: This would all be much simpler if E did not have non- 
> final-slots and all mutation or otherwise special slots were handled  
> by user code working with explicit slot objects...)
> 
> > Well, let's add the auditor first, instead of ...:
> >
> > interface FooGuard guards FooAuditor {}
> > def foo implements FooAuditor {}
> > def bar implements Nonsklarkish { ... foo ... }
> >
> > In both proposals, the Nonsklarkish can't see anything about foo in
> > this case, I think.
> >
> > To make it available, I'd assume this:
> >
> >  def foo :FooGuard implements FooAuditor {}
> >
> > Then Nonsklarkish knows that foo was coerced by FooGuard, because "def
> > var :guard" exposes "guard" to auditors automatically.
> 
> This notion causes a circularity problem with the object's self- 
> reference. (It also makes another lookahead mess in the parser, but  
> we've got lots of those already in object/def expression heads.)
> 
> def a {
>    to coerce(sp, ej) {
>      return sp.this()
>    }
> }
> 
> def b :a {
>    to this() {
>      return b
>    }
> }
> 
> The value of b is not determined until the guard a returns, but a  
> invokes b. Therefore the naming pattern of an object expression must  
> not have a guard.

That is annoying, but it's a problem E already has in other places (e.g.
"def foo extends makeBar(foo)"). For the cases supported by the "as"
syntax, there's no reason why the guard would call the object anyway.

I find it odd that we're being so careful to restrict what auditors can
see and do, yet guards are so powerful:

def obj as Auditor { ... }

def process(x :Guard) { ... }
process(obj)

The guard is free to substitute a replacement for obj, changing its
behaviour completely or getting access to every value passed to it.

> (Making b-inside-of-b be a promise until the guard returns makes a  
> messy edge case for auditors, but might be workable...)

> > Presumably for bindings the syntax would be:
> >
> >  def foo as FooAuditor {}
> >
> > But that gives Nonsklarkish the powerful FooAuditor, which seems
> > wrong, so I don't think I've understood this syntax.
> 
> It is inappropriate to use the 'as' syntax for rubber-stamps, yes. You  
> should really call it 'FooStamp' to indicate that it is a stamp.  
> Rubber-stamps are a degenerate, but supported, case of auditors.
> 
> Instead of using the 'as' syntax, you'll have to use the separate  
> guarding syntax.
> 
> def foo :Foo := { def foo implements FooStamp {} }



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