[E-Lang] '==' (was: Immutable map operations)

[Mark S. Miller]

At 04:43 PM Friday 3/23/01, Karp, Alan wrote:
>Mark Miller wrote:
>>
>> All selfless objects are immutable.  Selfish object may be 
>> mutable or not.  
>> Two selfless objects are == when they are indistinguishable.  
>> Two selfish 
>> objects are == when they are in the same object -- the result 
>> of the same 
>> act of object creation.  
>>
>
>So I asked myself, are there any times it would matter that two selfless
>objects are not in the same object?  Yes, I said to myself, when there are
>externialities.  Hmmm, I said.  What kind of externialities?  How about side
>effects, such as access counters?  Yeah, that's one.  

Selfless objects are necessarily immutable.


>Then there's always the destruction of one of them.

All selfless objects must be PassByCopy or PassByConstruction, referred to 
generically as pbc.  (All PassByCopy objects are also selfless.)  A resolved 
reference to a pbc object is always a near reference, a reference to an 
object in the local vat.  '==' among unresolved references throws an 
exception, since there isn't yet enough locally known to give a stable 
answer.  Two resolved references to pbc objects are therefore both near 
references, which therefore refer to copies of these objects in the local vat.

The vat is the smallest granularity of preemptive storage destruction in E.  
Therefore near references are guaranteed reliable: the designated object 
must continue to exist at least for the life of the object holding the 
reference.  If the vat containing them is destroyed, both objects disappear 
atomically and are not able to perceive a state in which one exists but the 
other is destroyed.  Within a vat, deallocation happens only by garbage 
collection.

Mutable objects can become inactive on their own choosing, as with a 
revocable forwarder, but as previously stated, selfless objects are 
immutable, so this soft form of destruction also doesn't apply.


>I guess I'd better be prepared to switch to
>the other one if the one I'm using goes away.  

If it's local and you're using it, it can't go away before you do.  If it's 
not yet local, you can't yet == on it.


>Of course, if they happen to
>be the same object, I only need to keep one reference around 'cause when the
>object's gone, it's gone.  So, == by itself doesn't tell me everything I
>need to know for selfless objects.

My design goal is that, in E, it does.  Furthermore, in E the implementation 
should be free to copy or share == selfless objects within a vat as it 
wishes, confident that this cannot have any effect detectable from E.


>We ran into this same issue with e-speak vocabularies (which are immutable).
>We decided the only meaningful definition of == was identical objects even
>for immutables.

Destruction is mutation.  Given your issues, I claim that your vocabularies 
weren't immutables.


        Cheers,
        --MarkM