Re: Bindings and guard-based auditing

Thomas Leonard <[email protected]>
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
On 25 May 2010 17:41, Kevin Reid <kpreid-M/[email protected]> wrote:
> On May 25, 2010, at 11:03, Thomas Leonard wrote:
>
>> For the slots-only case, I'm imagining that there's some method on
>> Slot
>> to get details for an auditor (getAuditionInfo or some-such). This is
>> only called for known slot types (FinalSlot, VarSlot, etc). For other
>> slot types, we pass no information to auditors.
>>
>> (yes, this makes some slot types special, but as I understand it the
>> bindings proposal makes certain binding types special)
>
> What do you mean by "binding types"?

I'm assuming I can't do:

def &&x := makeMyBinding(...)

> Note that 'CoercedSlot' does not mean 'a (container for a) slot which
> has been coerced'; it means 'a slot whose value *has been* coerced';
> it is basically GuardedSlot without the mutability.

I'm still confused, then. How can the value have been coerced, unless
it's a FinalSlot. Other slots change their value over time.

>> But in:
>>
>>  def &x := makeSlot(...)
>>
>> the information given up to an auditor would depend on makeSlot
>> (whereas
>> with bindings no information is given up), and in
>
> Is 'makeSlot' here a builtin or some user-defined function?

User-defined (but returning a slot wrapped in a built-in slot type if
it wants it to be auditable immediately).

>> For wacky slots:
>>
>>  def &&wacky := makeCoercedSlot(WackySlot, makeWackySlot(value))
>>
>> becomes
>>
>>  def &wacky :CoercedSlot[WackySlot] := makeWackySlot(value)
>>
>> where CoercedSlot is a trusted slot type which simply proxies to the
>> underlying slot, coerced by the guard. It gives up the guard
>> (WackySlot)
>> to the auditor, which can process it as it pleases. makeWackySlot
>> could
>> do the coercion itself if desired.
>
> I don't see what this CoercedSlot (please don't call it that, BTW;
> this is different from what CS in the GBA proposal does) adds;
> wouldn't it be sufficient to have the following?
>
>    def &wacky :WackySlot := makeWackySlot(value)

Yes, or even:

  def &wacky := makeWackySlot(value)

> In current (pre- or post-GBA) E semantics, this coerces the rvalue by
> WackySlot before storing it as the slot for 'wacky'.
>
> ...Oh, I see. We put the slot in a wrapper which is known to give
> reliable information to the auditors; in this particular case 'the
> behavior of this slot, as a slot, is that enforced by WackySlot'.

Yes.

>> The main difference is that bindings add new syntax (&&x and "def ...
>> as").
>
> As a historical note:
>
> The && syntax was added primarily so that sugar expansions which
> rebind values (such as &&, ||, and 'extends') can preserve binding
> guards.
>
> The 'as' syntax was added so that the bindings of object definitions
> could have information for auditors, without having to write e.g. def
> foo :DeepFrozen := {def foo implements DeepFrozen { ... }}.

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.

> How does your proposal handle the latter case? That is, in
>
>   def foo implements ... {
>     ...
>   }
>
>   def bar implements Nonsklarkish {
>     ... foo ...
>   }
>
> how does the programmer control the amount of information about foo
> which can be observed by Nonsklarkish when auditing bar?

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.

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.


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.