[E-Lang] Progress & Non-Progress Report

[Tyler Close]

At 10:28 AM 5/16/01 -0700, Marc Stiegler wrote:
>Tyler said:
> > >I've got a potential problem here in supporting this in Droplets. I have
>to
> > >be able to limit the lifespan of different timelines. This means that two
> > >references may refer to the same target object, but one of those
>references
> > >may be on a timeline that will be terminated while the other remains
>valid.
> > >A reference does not represent unlimited ability to send messages to the
> > >target. A reference represents the ability to send messages within a time
> > >window determined by the reference host. So, two references may have the
> > >same target, but different time windows.
>
>Since the answer to the following question hasn't appeared in the
>conversation, I guess I'll have to ask it :-)
>
>Why do you need to be able to time out different references differently? Why
>not just use a revokable forwarder that times out, if object 1 should only
>have a reference to object 2 for a limited time?

The time window is not to support proxy-style design patterns, but to 
implement garbage collection. It is similar to the way E allows you to set 
a timeout on a SturdyRef (though in Droplets, this timeout need not have 
anything to do with 'time'). The question we are currently pondering is 
therefore similar to asking if two E SturdyRef's with different expiration 
dates, but the same target object, are "==". Markm's currently proposed 
definition of "==" is at http://www.erights.org/elib/equality/same-ref.html:

"For any x and y, "x == y" immediately (synchronously) either returns true, 
returns false, or throws an Exception. If it returns true, then x and y 
designate the same object. If it returns false, then x and y designate 
different objects. If x and y are both Settled, then == must return either 
true or false. Therefore, if it throws an Exception, then at least one of 
the two operands was Unsettled at the time."

According to this definition, the two SturdyRef's are "==". I'm not sure 
this is the right choice (it may be). It is also tricky to implement.

As you point out, it is also possible to visualize this logic as a 
revokable forwarder. In this case, E's answer would be that the two 
SturdyRef's are not "==", since they refer to different objects.

This issue seems like a very good demonstration of Dean's position that the 
existence of "==" breaks useful uses of polymorphism. Essentially, we have 
two reference objects that we want client code to treat as if "==", even 
though they are not.

Dean, how does Joule provide hashtables without "=="?

Tyler