[E-Lang] Progress & Non-Progress Report

[Dean Tribble]

>My first question is actually at an even more basic level. In your 
>response, what do the verbs "comparison" and "matched" mean if there is no 
>"=="?

Turtles.  Definitely turtles all the way down.  :-)

I'll use vaguely E-ish syntax for the concepts:

   def a = x < y

translates to:

   def [a, aR] = new Promise()
   x.lessThan(y, aR)

Often, references will be "near" and "point" directly to a primitive 
object.  In Joule, however, they could also be transparent forwarders 
(e.g., promises, channels, etc.) to a primitive object, and everything must 
work out.  To illustrate the above, I will assume that both x and y are 
channels to integers (i.e., there are forwarders present).  This will let 
me walk through "bottoming out" to primitive objects.

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)

Note that because this is sent by the computation happening inside the 
primitive integer, the first argument is the integer itself, not the 
transparent forwarder to the integer.  The lessThanFrom message flows 
through the 'y' channel to arrive at the primitive 6 object.  As with 
lessThan, it checks whether the first argument is primitive.  In this case, 
it is, so it primitively determines whether 4 is less than 6, and forwards 
aR, the channel's distributor ("Resolves the Resolver" in E), to 'false'.

Note that the "bottoming-out" of transparent forwarders concept came from 
actors, though Joule definitely takes it to new heights or depths or 
something.  Joule has a few bottoming out techniques.  Here, it uses the 
"double-dispatch" pattern to bottom out, but the "respond" pattern (named 
"whenResolved" in E :-) is also used.  The basic observation is that only 
the primitives need resolved values, and they can primitively check for 
them, even though user code cannot.  Double-dispatch is used for numbers 
(and collections and a few other things) because it supports sophisticated 
but high-performance coercion as well (so the above example would actually 
use lessThanFromInteger or some such as the doubled message).

>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 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.  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? :-)

dean