Identity et al (was Re: [E-Lang] Authority -- what is its
Mark S. Miller
Mon, 22 Oct 2001 08:37:20 -0700
At 06:12 AM 10/19/2001 Friday, Jonathan A Rees wrote:
>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
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
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
> >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
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
>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
An excellent example of simultaneously supporting multiple perspectives.