# [E-Lang] Progress & Non-Progress Report

Dean Tribble tribble@e-dean.com
Thu, 17 May 2001 15:50:38 -0700

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

```