[E-Lang] Progress & Non-Progress Report

[Tyler Close]

At 03:50 PM 5/17/01 -0700, Dean Tribble wrote:

>Given:
>
>   def x = 4, y = 6
>
>and assuming those introduce an otherwise completely spurious intermediate 
>forwarder, the lessThan message just propagates directly through channel x 
>to be delivered to the primitive 4 object.  The primitive implementation 
>of lessThan checks whether the first argument is a primitive 
>number;  since it is not, it sends a message to the "y" argument to make 
>it y's problem:
>
>   y.lessThanFrom(4, aR)

So a statement like:

      0 > i

would not answer the question: "Is i a negative integer?". "i" could be 
anything and can answer the question in any way it chooses.

What happens if "y" does not have a method named "lessThanFrom/2"?

Can an "==" invocation result in a "NoSuchMethodError" if the arguments are 
of incompatible types?


>>Is "==" just another method on the object?
>
>Essentially, though there is no primitive notion of identity equality 
>because the only thing it means to point at an object is that you can send 
>messages to it.  There may not be a single locus process, etc. that is the 
>thing that has identity.  There is some small primitive support for 
>classes that wish to represent their identity as simply the possession of 
>a specific nonce, but that is less frequent than might be expected.

If there is no primitive notion of identity equality, does that mean that 
using a pointer to a remote object as a key in a hashtable will always 
result in remote method invocations during a hashtable search? If the 
answer to this question is yes, then Joule also has to deal with the 
"settling of a forked reference" issue, but instead of resolving the 
reference once, upon receipt, it essentially resolves it every time it is 
used. This seems to pretty much preclude using remote references as keys in 
a hashtable.


>>If so, doesn't this mean that your hashtable implementation "relies" on 
>>the keys? If so, how can you make robust "server" objects with brittle 
>>hashtables?
>
>If the server has an internal hash table with internally defined keys, 
>then the server is only relying on its own stuff.
>
>If the server is using objects provided by the client for anything, it 
>must not rely on promptness of those objects unless it makes prior arrangement.

If "==" is just another method on an object, then the server also must not 
rely on the object providing a stable response to the "==" method (ie: "a 
== b" is true and then later "a == b" is false). Does this mean that robust 
"server" objects require a vouching service for all client provided objects 
that are to be used as a key in a hashtable?

>   In E, that prior arrangement is made by requiring near objects or just 
> using the identity of settled remote objects.  Joule has various other 
> mechanisms by which robust servers could arrange to not care about 
> promptness of arguments to send, but I haven't swapped in quite enough to 
> describe any yet.  :-)
>
>(These are fun questions, BTW.  Any more? :-)

I think this is boiling down to two main issues:

#1 Without a built-in "==", it is not feasible to use remote pointers as 
descriptors, since any check requires a remote invocation. For example, 
this means hashtables should not use remote pointers as keys.

#2 A built-in "==" guarantees the properites of the "==" operation. This 
reduces the need for vouching services. For example, naive use of a 
hashtable is safe with a built-in "==".

These two issues give me concerns about the type of world I end up in 
without some kind of built-in "==". I was hoping that these questions would 
reveal some form of weak "==" in Joule that would somehow offer reasonable 
solutions to these issues. Of the two issues, the second seems likely to be 
the most bothersome. How do you cope with this in Joule?

Tyler