[cap-talk] __equalizer and such E operations

Jonathan S. Shapiro shap at eros-os.com
Tue Feb 12 23:15:30 EST 2008


On Tue, 2008-02-12 at 22:25 -0500, Kevin Reid wrote:
> 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).

First, I believe Kevin is correct about the conflation, but matters are
worse than he suggests. In a typical cap-OS, things like memory pages
may be shared, with the result that there is no clear boundary you can
point to and say "that is the internal state of object O". This is also
true in programming languages (because repr state can be indirect), but
the idioms of OO programming tend to have clearer encapsulation of
object representation than cap-OS systems tend to have. Not universally,
but generally.

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

I am not entirely convinced that interning is infeasible. Is there some
reason that a promise cannot spontaneously resolve itself before being
forced?


shap



More information about the cap-talk mailing list