[cap-talk] __equalizer and such E operations

[Kevin Reid]

On Feb 12, 2008, at 20:39, Jed Donnelley wrote:
> I may quickly get deeper into the language structures that is  
> meaningful for me to follow, but just briefly on:
>
> On 2/12/2008 4:27 PM, Kevin Reid wrote:
>> I'm not sure what primitives you would consider to 'relate to the  
>> base domain protection',
>
> I guessed that phrase might be problematic.  It seems that trying  
> to say it in two ways (info/operations that couldn't be otherwise  
> programmed - necessarily primitive) didn't help?

I understand the concept of minimal primitives. I'm not sure exactly  
what would or wouldn't be 'base domain protection' in E.

> Regarding:
>
>>    __auditedBy (tests whether an object has been approved by a
>> particular auditor; this may be analogous to the "MyCap?" being
>> discussed)
>
> No, "MyCap?" is quite different.  I think the closest analog in the  
> OO language area is being in the scope of an object method and  
> therefore being able to operate on the private parts of an object.   
> As Charlie noted, in the language arena this scoping is implicit.   
> In an OS or network context, there is no such scoping to rely on.   
> There has to be some means for an executing program to demonstrate  
> it's permission to get access to the 'insides' of an object that it  
> was passed as a parameter.

You seem to be conflating what I and E would consider two distinct  
cases: the code of an object (or process) operating on

   - that object's internal state (in a cap-OS, its memory pages,  
registers, etc.), or
   - the internal state of a distinct object (which was supplied as  
an argument), for which it has prior permission.

In E, the first is lexical variable access. The second is unsealing/ 
rights-amplification, which can be implemented by way of __auditedBy  
(or a map, but then you're using __equalizer).

> Are these "selfless" objects in some sense "built in"?

In practice (current implementations), yes, because we haven't  
written the auditors which will approve selflessness implementations;  
in principle, no, users can write arbitrary new ones.

>> If both objects are Selfless, both are invoked, and the resulting
>> lists compared recursively; otherwise, neither is.
>
> I wonder if an example might help?  On the surface, making objects  
> selfless appears to make more work to compare them when a pointer  
> compare would otherwise suffice.  What's the offsetting gain?

If the 'same' value has been computed multiple times (or passed over  
a network), then it cannot have the same creation identity;  
therefore, a structural comparison operation is useful. (Interning is  
not feasible because of promises.)

If a non-primitive comparison operation to compare data structures,  
distinct from built-in pointer comparison, were to be implemented in  
E, then it would end up being essentially identical to E's current  
__equalizer; except that, because unrestricted pointer comparison was  
already exposed, we would lose the benefit of being able to conclude  
behavioral equality of clients from structural identity of values.

(This is not the best of arguments; ask MarkM if you want a better  
one. I like E's design but I don't know everything that went into it.  
To start with, there's probably some things to be said about  
distributed programming.)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>