[E-Lang] Progress & Non-Progress Report

[Mark S. Miller]

At 10:13 AM Monday 5/14/01, Tyler Close wrote:
>>>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?
>
>The as yet unreleased Droplets 2.0 implements a reference semantics that I believe obeys E's defined semantics, modulo the ERiaSR issue.

 From what you say below, I believe this is due to my lack of precision in 
trying to state E's semantics.  The remarks below indicate that Droplets 
diverges from the semantics I'd always intended to specify.  Hopefully, the 
new pages are more precise.  (Though they also go beyond the originally 
intended semantics.)


>In the current implementation, the fork of any reference is a resolved far reference. [...]

When I'd read to this point, I thought "huh?  How can the fork of an 
Unresolved reference be Resolved?  You don't generally know what it 
designates yet."  Your explanation of this below is our key divergence.


>>>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?
>
>The forked one of course. Using the original swiss number would pretty much defeat the purpose of forking.
>
>> If the former, then
>>forking gives them a different sameness identity,  This makes hashtables
>>containing them arrive as different hashtables.
>
>The forked reference is not "==" to the original reference. The two references are on different timelines and so cannot be "==". A hashtable containing such a reference would indeed arrive as a different hashtable. It's likely that there is a difference in "==" between Droplets and E here. What are the issues here?

Yes, this is the key difference.  In E, Resolved arguments as they are sent 
are "==" to the arguments as they arrive.  Yes, this does create a conflict 
regarding timelines, as I stupidly hadn't noticed till recently.

In the current E implementation, this conflict is dealt with, sort of, by 
always having an inter-vat reference arrive as an Unresolved reference (this 
is the Lost Resolution bug).  This breaks the above 'Resolved arguments as 
they are sent are "==" to the arguments as they arrive', but leaves us 
instead with 'Resolved arguments as they are sent are *eventually* "==" to 
the arguments as they arrive'

In the proposed protocol, the issue is dealt with by using the WormholeOp to 
reconcile the timelines before the forked reference arrives in the receiving 
vat (VAtB).  The WormholeOp page explains some other possible options.


>>I'll wait for clarifications of the above issues before proceeding further.
>
>There is one problem on my TODO list for the reference implementation. The problem is that the fork of an unresolved promise for a pass-by-copy object is a resolved far reference to that pass-by-copy object. This forked reference never gets collapsed to a local copy of the target pass-by-copy object. I've been mulling different ways of solving this, but haven't found one that I really like, so I've been procrastinating. My favorite contender is to have the receiving Vat do another "yourself/0" on the forked reference.

In E, a Resolved reference to a PassByCopy object is always a Near reference 
to a PassByCopy object (and therefore, to a local copy if needed).



        Cheers,
        --MarkM