[E-Lang] Progress & Non-Progress Report

[Tyler Close]

At 09:00 AM 5/14/01 -0700, Mark S. Miller wrote:
>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?

All of the above. I just wanted people to think through the differences and 
hopefully come to the conclusion of the next sentence... that these 
differences can be hidden.

> >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?

The as yet unreleased Droplets 2.0 implements a reference semantics that I 
believe obeys E's defined semantics, modulo the ERiaSR issue.

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

In the current implementation, the fork of any reference is a resolved far 
reference. The only exception to this is a resolved reference to a 
pass-by-copy object. The fork of a resolved reference to a pass-by-copy 
object is a copy of that pass-by-copy object.


> >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?


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

Tyler