ALU capability (was Re: [E-Lang] Authority -- what is its dual?)

[Jonathan A Rees]

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.

-----------------------------------------------------------------------

Very long reply.  Don't reply to all of it or I won't have time to
read your reply!

   Date: Fri, 19 Oct 2001 02:36:35 -0700
   From: Dean Tribble <tribble@e-dean.com>

   Your message may be the most interesting message that I have completely 
   disagreed with in a long time :-)  I didn't incorporate many smileys, and 
   it's late, so please interpret everything with the best of intentions :-)

Ditto.

   >        def _ :any { match [verb, args] { --STUFF-- } }
   >    ==
   >        (lambda (verb . args) --STUFF--)

   This sounds like "Socrates is a man so all men are Socrates".  In the 
   E/Joule computational model, lambda is a degenerate form of object; that 
   does not mean that all objects are expressible as lambda.  Also, in Scheme, 
   vectors, lists, etc. are not objects, and they can't be just swept them 
   under the rug. Scheme has specific. built-in magic data-types that cannot 
   be emulated/extended/anything by programmers.

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.

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

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

   Then it probably was not the kind of object you were expecting.

I'm trying to find out whether a particular object is one that I'm
expecting.

   I will describe the primary mechanism here.  I will not attempt to bottom 
   it all out in this message, but it can be done.  You ask your 
   verifier/brand(in Joule/E respectively) to "verify" the object.  It sends a 
   challenge to the object.  In response to the challenge, the object (iff it 
   is the kind of object required by the verifier) stores a pointer to itself 
   in a location that is closely held by the object expected (e.g., system 
   purses) and the verifier (e.g., the purse verifier).  The object then
   returns with no value.  The verifier then looks in the shared, closely held 
   location, an extracts the direct pointer to the object, and returns it to 
   you.  You now have a direct pointer to an object that obeys known code and 
   a known contract, which you now use instead of the argument you started 
   with.  This is all semantically implemented with message sending, though it 
   is trivially optimizable in the typical case in which no-one is playing 
   games with you.  If there were semi-transparent forwarders around the 
   object, they've been stripped off.

   I expect that this should sounds very familiar to you, so I may be not 
   understanding the point you are trying to make.

Actually it's not familiar, and I apologize for my ignorance.  Not
only do I not recall hearing this solution before, I can't think of a
way in which I might have found it out if I were looking..

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.

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.

However, it looks like this might be strong enough to enable one to
*formally* prove results such as a+b = b+a for all integers a and b.
Has anyone done so?

   I have exactly the opposite reaction:  multicast message passing is how the 
   world works at all levels, and every other approach is sloppy thinking.

Tell me how it works (or give a reference) for quantum mechanics and
QED?  Are you thinking of Bill Rozas's masters thesis?  All the usual
descriptions are bird's-eye views, and talk about encapsulation issues
such as lack of information from a third-party perspective, using
theorems and so on.

   >- It accounts poorly for symmetric interaction, such as chemical
   >   reactions and gravity.

   The computation of these things is necessarily asymmetric in real 
   computers.  If you want to come up with a model that pretends to be 
   symmetric, you need to precisely talk about the asymmetric operations that 
   accomplish that.  Computers give you no other choice.

This is the crux of the matter, I think.  I am not talking about the
same kind of use of programming languages; the operational
interpretation is only half the story.  See below.

   >- It deals poorly with information-oriented phenomena such as
   >   mathematical objects, copying,

   This are not clear enough examples for me to respond.  Can you clarify?

If an object has identity, it (the object itself, not its reference)
can't be copied (and then, say, disconnected in useable form) without
loss of information.  The other operations I mention are variants of
copying.  I suppose selfless objects together with verifiers for them
allow you to simulate data, but it seems very roundabout to me.  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?

I know you'll come up with some clever response to this last
example...  the details aren't rigorous.

   >   E takes a step in the right direction by introducing the
   >   "selfless" notion, but this isn't enough.
   >
   >- It usually has a very imperative, operational flavor to it.
   >   It begs you to write a recipe, not to describe the result that you
   >   want as functional languages do.

   Almost ever successful "functional" or "logic programming" program is 
   written by people who thought operationally about the results.

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.

   I've seen 
   lots of amateur prolog programs that took forever on trivial problems 
   because they were written "declaratively".

Not the situation I'm talking about.  To write good puns as above is
very difficult.  Even in working Prolog programs the imperative
interpretation is often in your face all the time.

   In addition, with the ability 
   to raise your expressive level of abstraction, you can make the operations 
   appropriately abstract for the problem you are solving (e.g., match this 
   graph pattern).  This supports conceptual decomposition and strong 
   separation of concerns, without sweeping real computation issues under the rug.

Mathematics is the traditional way to be abstract, and it's exactly
the opposite of object-oriented.  Everything is passive except the
mathematician.

   This is where OO design comes in.  When you take security concerns and a 
   few other heuristics into account, most such separations are pretty 
   easy.  And because of encapsulation, they are also easy to change.

OO may give you encapsulation, but there are plenty of non-OO
paradigms that have encapsulation as well, such as static ADT's (CLU)
and axiomatic theories (e.g. Larch).

I must not be privy to those heuristics, since I'm always getting it
wrong.  Can you mail them to me?

   >- It's a poor match both syntactically and semantically with
   >   natural language, making it awkward for expressing things that are
   >   in people's minds.

   DWIM died a long time ago.

I'm not talking about DWIM or the AI problem.  I'm talking about the
ability of people to convert their ideas, naturally and without
distractions (such as objectness), into
simultaneously-declarative-and-imperative form, and about their
ability to do the inverse when they need to (someone else wrote the
code or they forgot what it did).

   OO thinking is valuable because it makes it possible to get a crisp handle 
   on the abstractions being used to solve the problem.

Then why is it not embraced by mathematicians?  I have immense respect
for them as problem solvers, even if they often appear to be idiots
savants at times.  Maybe their notations suck, but that's mostly a
syntactic problem.

   It supports strong separation of concerns.  It straightforwardly
   models responsibilities and other security properties.  Etc.  No
   other approach has such breadth.

I agree, it's a technique that should be used for all these things.
But it shouldn't be advocated as the fundamental grammatical construct
in all expression in a proposed general-purpose programming language.
It imposes the right structure for computing-in-the-world, but too
much structure for computing-as-thought-amplification.  We should be
thankful that there are situations in which responsibility and
security aren't issues - that's what we're trying to achieve by making
it easy to take care of them.

At this point one of us will probably ask "what do we mean by OO" and
whether embeddings (of data-oriented in OO) are good enough.  If we
agree that OO = lambda-calculus basically, then we probably agree more
than we disagree.  Maybe it's latency and network partitions that I'm
really worried about, and you'll tell me how to think about these.

This is fun!  I've been unhappy about this for over 15 years, and it's
a luxury to find people who are aware of the issues and solutions.
Thanks.

Jonathan