[E-Lang] Progress & Non-Progress Report

[Mark S. Miller]

At 05:31 AM Monday 5/14/01, Tyler Close wrote:
>How do you tell the difference between the unresolved fork of a far 
>reference and the resolved fork of far reference? 

I'm not sure what level this question is at.  In the semantics?  In the 
implementation?  In the protocol?  The semantics define these as distinct on 
the pages you've seen.  The implementation and the protocol represent them 
as distinct.  In the protocol it's the difference between, for Unresolved 
forks: Vow3Desc, provideFor/3 (the message "provideFor" with three 
arguments), and acceptFrom/3, on the one hand, and, for Resolved forks, 
Far3Desc, provideFor/4, and acceptFrom/4.

Perhaps you're asking how do we decide whether a fork should be a Resolved 
fork or an Unresolved fork?  In order to "Preserve Passability" (on the 
WormholeOp page), or similarly, in order to implement "Args Stay Resolved" 
http://www.erights.org/elib/equality/same-ref.html#args-stay-resolved , the 
fork of a Resolved reference is Resolved.  

On the flip side, in the anticipated implementation, the fork of an 
Unresolved reference is Unresolved,  1) because we don't generally know what 
to resolve it to, and 2) because we're not obligated to make a Resolved 
fork, so it's cheaper not to (under the assumption that Resolved forking is 
more expensive, which you may cure us of).

Once the resolution of an Unresolved reference is determined, the 
implementation must eventually cause the reference to become the Resolved.  
This applies equally to an original Unresolved reference and to its fork.  
Therefore, if the target of an Unresolved reference is already determined, 
the semantics allow the fork of such an Unresolved reference to be a 
Resolved fork, although the anticipated implementation does not make use of 
this freedom.  I don't think this matters, but I mention it for completeness.


>If these two types of 
>reference can be made indistinguishable to the E programmer, then there is 
>no need for any of this fuss. 

Agreed!  It all hinges on that "if".


>This is the approach that Droplets takes.

Great!  Let's see if Droplets' solution translates to E.


>For the specific example that you raised, using a far reference as a key in 
>a pass-by-copy hashtable, the only requirement is to ensure that the forked 
>far reference supports EQ semantics from birth, rather than just from 
>resolution (as normal references do). 

Do I take it from this statement that normal references in Droplets, as in 
E, only support sameness from resolution?  And that therefore they only have 
a sameness-relevant swiss number starting from resolution?  What then of the 
fork of an Unresolved reference?  If this is also Unresolved, then it seems 
we have similar stances on when a fork is Resolved vs Unresolved.

(Note that I avoid saying "EQ" because Lisp's traditional definition of EQ 
would have it correspond to Java's "==" rather than the E language's "==".  
I call the latter "sameness", which is a terrible word, but is distinct from 
terms that have already been used up with a different meaning.  Since our 
meaning is similar to that defined by 
http://linux.rice.edu/~rahul/hbaker/ObjectIdentity.html , perhaps we should 
adopt "egal" instead?)


>In Droplets, this is accomplished by 
>using the swiss-number for all EQ operations (actually, the whole URI gets 
>used). The forked far reference's swiss-number remains constant for its 
>entire lifecycle.

But which swiss number?  Is it one associated with the forking, or is it the 
swiss number of the reference they were forked from?  If the former, then 
forking gives them a different sameness identity,  This makes hashtables 
containing them arrive as different hashtables.

If the latter, you have a pluggable security hole.  The swiss number not 
only represents the identity of the object for sameness testing, it also 
provides authority to obtain access to the object itself.  The forked 
reference should provide access only to post-X Carol, as previously 
discussed.  The Far3Desc, which the proposed CapTP protocol would use to 
send a forked Resolved reference between vats, sends a cryptohash of the 
swiss number (the swissHash) for sameness testing purposes, and sends the 
nonce for introduction purposes.  The nonce only introduces VatB, by 
acceptFrom/4, to Carol as registered by provideFor/4.  The provideFor/4 
message is sent by VatA after X, so the nonce only gives access to post-X 
Carol.

I'll wait for clarifications of the above issues before proceeding further.



        Cheers,
        --MarkM