David Hopwood david.nospam.hopwood at blueyonder.co.uk
Mon Jun 27 20:29:24 EDT 2005

Ka-Ping Yee wrote:
> + the synchronous {pi} calculus
>
>     [...]  Also, use the Greek letter pi.

I.e. $\pi$-calculus, and also $\lambda$-calculus.

# From a lambda calculus perspective, an object definition is like a lambda
# expression, in which the (implicit) lambda parameter is bound to the
# incoming message, and the body (implicitly) does a switch to select a
# method. The methods themselves are the cases of this switch. The delivery
# of a message to an object is the application of an object-as-closure to a
# message-as-argument. An object's behavior is indeed a function of the
# message it is applied to. (This view of objects goes back to Smalltalk-72
# [GK76] and Actors. See [Shroff04**] for more.)

Ka-Ping Yee wrote:
> It's not "like" a lambda expression, it *is* a lambda expression.

Strictly speaking, it *is* a lambda abstraction.

"object definition"            : "lambda abstraction" as
"object definition expression" : "lambda expression".

The sentence "An object's behavior..." is redundant. Avoid unnecessary
parentheses, especially around multiple sentences. "for more" => more of what?
Here is my suggested rewrite:

From a $\lambda$-calculus perspective, an object definition is a
lambda abstraction in which the parameter is bound to the incoming
message, and the body selects a method to run according to the message.
The delivery of a message to an object is the application of an
object-as-closure to a message-as-argument. This view of objects goes
back to Smalltalk-72 [GK76] and Actors, and is hinted at earlier in
[Hoare65]. Also see [Shroff04**].

[Hoare65] Algol Bulletin 21.3.6,
C. A. R. Hoare: Record Handling, pages 39-69, July 1965.
<http://www.softeng.ox.ac.uk/Jeremy.Gibbons/wg21/algol-bulletin/A21/P36.HTM>

Here's the relevant hint about lambda objects:

If the proposals 7.2, 7.3, and 7.4 are accepted, we reach a situation in
which a record class declaration has exactly the same form and effect as
a (function) procedure declaration, except that it delivers as its value
not a simple quantity, but a reference to the record consisting of the
values of all its local quantities at the time of exit from the procedure.
Thus we have worked our way through to a startling simplification, which
enables record class declarations to be treated largely by the same
mechanism as procedures. At run time the mechanism is also very similar.

Note that these procedures are general closures. Although the paper doesn't
explicitly say so, it is possible to tell from the Algol context and the
use of the term "display" that they are lexically scoped (see
<http://home.pipeline.com/~hbaker1/ShallowBinding.html>), and section 6.5
suggests that they be GC'd. Section 7.2 even suggests computed fields
consistent with Bertrand Meyer's "Uniform Access Principle" ("If this
procedure were parameterless, its use as a function designator would have
the same appearance as a field designator.") OTOH, Hoare's proposal doesn't
support fully polymorphic references to different record types (as is clear
from the example in section 7.5), so his records are not quite objects.

====

# Java is loosely in the monitor tradition. Ada, Concurrent ML, and the
# synchronous $\pi$-calculus are loosely in the rendezvous tradition.
# With minor adjustments, the following comments apply to both. We ignore
# the additional complexities that come from Java's loosely consistent
# memory model, and assume simple sequentially consistent memory.

>     What does "loosely consistent" refer to?  Either explain this or
>     delete it.

The paper isn't actually ignoring these complexities: they're just not
relevant to the Java examples because those examples are all properly
synchronized. They would be relevant if we needed to consider security
consequences of the Java model in detail, but that's out of scope for
this paper. So delete the whole of the last sentence.

If you did need to reference Java's memory model, incidentally, the
reference would be:

[MPA04] Jeremy Manson, Bill Pugh, Sarita Adve, JSR-133 Expert Group,
JSR-133: Java(TM) Memory Model and Thread Specification
Public review version, February 2, 2004.
<http://www.cs.umd.edu/~pugh/java/memoryModel/PublicReview.pdf>

Ka-Ping Yee wrote:
> - E has no classes.  The expression beginning with
> + The expression beginning with
>
>     You don't have to say that E has no classes.  It doesn't
>     matter.  Just describe what E has.

Readers are likely to be familiar with class-based OO languages, but
not necessarily with lambda-based ones. I think the sentence is useful.

--
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>