Identity et al (was Re: [E-Lang] Authority -- what is its dual?)

[Mark S. Miller]

At 06:12 AM 10/19/2001 Friday, Jonathan A Rees wrote:
>Executive summary:
>
>1. On the detailed technical question, JAR is wrong and Tribble is
>   right, perhaps modulo latency and partitioning issues.
>   JAR didn't know about Joule's clever challenge/response solution.
>
>2. On the engineering question, JAR is right and Tribble is wrong.
>   Tribble and JAR have different views on what programming is about.

MarkM's view (custom crafted for this thread): Programming is about having 
your cake and eating it too.


>Sorry, I wasn't talking about Scheme; I'm talking about a Scheme
>subset in which EiaO, i.e. the only primitive object creation is
>LAMBDA and the only operation is invocation - no primitive numbers, no
>EQ, etc.

Sounds like a good step towards Actors.

>   I care [about T] because they helped get energetic secrets correct
>   in Joule.  I think that'as outside of the scope of this discussion,
>   however :-)
>
>Wow, that's the first I've ever heard of this!  I knew some people
>liked the object system, but I never heard of anyone building on it
>intellectually.  Tell me more.

I don't know if it'll make any sense out of context, but the Energetic 
Secrets chapter of the Joule manual is at 
ftp://ftp.webcom.com/pub1/agorics/postscript/MANUAL.B17.ps.Z .
The experience of trying to make this work under open systems constraints 
revealed some non-obvious problems which we can discuss if anyone's 
interested.  As a result of these problems, E chickened out and retreated to 
"a message selector is simply the message name string as it appears in the 
source program".  No lexical lookup step in sight.  Dean is still trying to 
argue me into at least a T-like position, which is intermediate between the 
two.


>   >I should say that I'm worried about the version of EiaO, where *all*
>   >you have is message passing -- no identity or equality.  We might call
>   >this "all you can do is send a message" or AYCDISAM, but I'll call it
>   >"strong EiaO" instead.
>
>   This should be called "no eq"
>
>I would stick by my use of the term "identity", since I admit the
>possibility of stateless objects that have identity, but I have no
>objection to "no eq".  This would be more trouble than it's worth to
>pin down rigorously, so let's move on.

I prefer AYCDISAM, since that expresses the hard constraint that Hewitt 
first articulated, and that only some Actors languages (including Act-1) and 
Joule have successfully achieved.  I was going to suggest Purely Message 
Mediated Computation, or PMMC, which amounts to much the same thing.  A 
primitive 'eq', such as E provides, in only one of many ways in which a 
language can fail to be AYCDISAM.

Actually, neither AYCDISAM nor PMMC is quite right either.  Neither Hewitt 
nor Dean are arguing against primitive objects (or "rock bottom actors") 
like integers. True AYCDISAM would force "3 + 4" to proceed by having 3 send 
a message to the "+ 4" message, and eventually to both "+" and "4".  "4" 
could only interact with the message it receives by sending a message to it. 
While this doesn't quite fall of the cliff of infinite regress, it comes 
close enough to create a explosion of tedious messages for very little 
purpose.  It also starts to become fantastic to imagine that this explosion 
of messages could actually be optimized into a single ALU "add" operation.

Rather, what Actors, Joule, Smalltalk, and E all do is to have "3", by magical 
means available only inside the kernel's implementation, test whether "4" is 
indeed a primitive integer.  If it is, then it sucks the bits out of "4" and 
proceeds to do ALU arithmetic.

Where some Actors languages and Joule get it right, and Smalltalk and E get 
it wrong, is in the design of the actions by the primitives when the test 
fails.  This is the bottoming out issue that at least Henry Lieberman has 
explained in the context of Act-1.  The essential difference is whether 
computation seems to be mediated only by messages.  Put another way, since 
user code in these systems can do nothing other than send messages, the 
issue is whether they can abuse the test-failure behavior of the primitives to 
effectively engage in behavior that goes beyond message passing.  In 
Smalltalk and E they can.  This doesn't hurt any of E's security goals, but 
it does hurt extensibility, as in the failed LazyMaker explained below.

Dean, could you explain how "3 + x" proceeds in Joule?  I think we need the 
concreteness before we proceed.


>   >Actually weak EiaO doesn't really qualify as
>   >EiaO, since identity can be used to implement passive objects
>   >(e.g. numbers) that are never sent messages.
>
>   Of course it qualifies:  the big distinction we are making is between magic 
>   built-in datatypes that the user cannot emulate vs. everything has a 
>   uniform object semantics.
>
>But if there's EQ, then one user can define a built-in datatype that
>no other user can emulate.  For example, I can define particular
>objects to be boolean true and false, and allow no other objects to
>qualify.  If others are obligated to work with me (I'm the boss or the
>police, etc.), then I'm effectively a "system", so what's the
>difference?

The difference is that, in Act-1 or Joule, a user-defined transparent 
forwarder in front of an object cannot be distinguished from the object 
itself.  This means, for example, that a lazy evaluator that will compute 
and then become a number can be provided anywhere a number is expected.  The 
LazyMaker at http://www.erights.org/elang/blocks/defPlumbing.html is as 
close as E can come, but it fail badly.  For example, "3 + lazyNum" will not 
work in E.


>I'm worried about the necessity of a having a private communication
>path (capability) from object to verifier.  Digital signatures don't
>have this property, which makes me worry that the approach is flawed,
>or at least not robust to partitions.

This doesn't apply to Act-1 or Joule, but a hypothetical AYCDISAM E wouldn't 
need to worry about this issue since all E's AYCDISAM-violating constructs 
only operate between mutually-near objects.


>I'm also bothered that state and timing are involved in extracting
>information.  If the object and/or verifier are slow to respond, and I
>get bored waiting for an answer, then that's not a negative answer,
>it's an I-don't-know.

I'm mildly bothered by the state (in the same way I'm bothered by the 
assignments in Scheme's canonical expansion of letrec).

I'm both surprised and very disturbed by the timing dependence.  I thought 
Dean had a timing-independent solution.  There is no timeout long enough to 
guarantee success when the semantics of the construct says we should succeed.
I'd prefer that these constructs wait forever if necessary.  Dean?


>[...] I suppose selfless objects together with verifiers for them
>allow you to simulate data, but it seems very roundabout to me.

This is why I started off with having one's cake and eating it too.  Many 
things that now seem natural to us, like using tail recursion for loops, 
must have seemed terribly roundabout to people used to compiling Fortran or 
Algol.  These "simulations" are explanatory stories and constraints on the 
semantics.  As Dan Ingalls says, in the implementation "you can cheat as long 
as you don't get caught".

Ken, can you tell the story of Cordell Green inventing logic programming but 
not knowing it, because, without knowing it could be made efficient, he 
imagined it was only a technique for simulating computation.

The "eating it too" is that we shouldn't lose the advantages of other 
valuable programming paradigms when we incorporate a new one.  We should 
design languages that allow us to reason about the same program using 
multiple perspectives.


>In the real world (common-sense version) there is data and there is
>transparency, and I exploit them all the time.  Maybe I use my eyes
>(unreliable but mostly effective) to verify that the thing in my hand
>is a pencil and not an impostor, but does that mean that the pencil
>knew about my eyes when it was manufactured?

So, the question is, how does Joule support this programming perspective any 
less well than Scheme?


>They have to because they want to run their programs.  But in the
>style I strive for, the ideal program is a pun, simultaneously
>declarative and imperative.  When a human first reads it, it's
>understood declaratively, and only then, when someone (human or
>computer) cares about running it, is it understood imperatively.  The
>idea is to isolate the user from implementation details such as
>inherent asymmetry.

An excellent example of simultaneously supporting multiple perspectives.


        Cheers,
        --MarkM