I got the following interesting message from a fellow who has
difficulties posting to the list, with a request to forward it.
I'll reply to it later.

Regards,
Joachim

-------- Original Message --------
Subject: Re: Messaging vs. subroutines
Date: Mon, 17 May 1999 16:54:46 -0300
From: Jecel Assumpcao Jr <jecel at lsi.usp.br>
Organization: University of Sao Paulo - Brazil
To: Joachim Durchholz <joachim.durchholz at munich.netsurf.de>

Hi,

it is very hard for me to post to the Squeak list (nothing I send
there makes it, but no errors are returned. The only way to get an
email through is for me to telnet directly to c.cs.uiuc.edu and
type it in their machine) so I am just sending this to you. Please
feel free to forward this to the list if I think it might be of
interest to others.

First, let me tell you my experience with Smalltalk. I was very
frustrated when I read the special issue of Byte in 1981 because
I didn't understand what they were talking about. I know a *lot*
of programming languages and learned all by reading just short
descriptions of them, except for Smalltalk. Then I got the famous
"blue book" and was still frustrated because there were circular
definitions everywhere. I too wanted some analogies with traditional
languages. I got that in the Smalltalk/V manual, which showed
Pascal and Smalltalk code side by side (this manual is available
online in the Smalltalk Express package at ObjectShare).

As I finally got what object oriented programming was all about
(studying Actor languages from MIT really helped) I saw that the
approach in Smalltalk/V might be dangerous - by taking analogies
too seriously (method == subroutine) you might never learn the
real concepts.

Joachim Durchholz wrote:
> 
> jecel at lsi.usp.br wrote:
> >
> > I think it would be fair to say that Joachim examined the source code
> > for the Squeak VM and found the messages were IMPLEMENTED AS
> > subroutines. That is not the same as saying messages ARE subroutines.
> 
> Fully agreed. But once I had seen that they were implemented as
> subroutines, I didn't see anything that made them more special than
> subroutines. Well, with one exception, of course: dynamic dispatch is
> novel, but not novel enough to declare that message passing is totally
> different from subroutine calls.

We are talking about a particular implementation: Squeak 2.4. Who
knows if this will be true for Squeak 3.0?

Self 4.0 from Sun also implements message passing as subroutine
calls. But I implemented tinySelf 1 with a very different mechanism
and yet hope that most Self 4 code will run on it. For preliminary
results see http://www.lsi.usp.br/~jecel/tiny.html

In my next implementation, message passing will be exposed as a set
of seven meta-objects (taken from Jeff's CoDA):

   - send: runs on behalf of the message sender and knows how to
           talk to the receiver's accept meta-object
   - accept: negotiates the transfer of the message with the other
             object's send meta-object
   - queue: decouples message acceptance from message reception if
            necessary
   - receive: knows how to get more messages for an object when it
              finishes running the current method
   - protocol: knows how to look up messages in a list of dictionaries
               to find a corresponding method
   - execution: knows how to get resources from the underlying
                platform (cpu, OS, rest of the VM) to actually get
                the method running
   - state: knows how to access the local data (instance variables)
            for the object

If you use the default set of meta-objects, then a technique called
"partial evaluation" will eliminate most of the overhead implied
here and the code will be reduced to a subroutine call. But you
will have to option of replacing any of these seven meta-objects
with your own variation in order to implement distributed or parallel
systems, and the resulting compiled code will be very different
from a normal subroutine call.

> > To use the example by Randal L. Schwartz: if you look at the bytecodes
> > generated by the compiler for #whileTrue: or #ifTrue: you might
> > conclude that blocks ARE the same thing as blocks in Algol or Pascal.
> 
> No. The internals are quite different. Besides, the parallel doesn't
> hold: looking at the bytecodes for #ifTrue: shows that blocks are the
> same as Algol blocks within the context of #ifTrue: only. Examining the
> VM to find out how messages are passed reveals how message passing is
> done in every case.

It is this "every case" where we disagree. Squeak is always evolving.
People pointed out that Smalltalk-72 (where the terms came into
use) was very different and I am showing how future Squeaks might also
be very different. You have looked through the whole source of
Squeak 2.4 and feel you have covered every case. I see many
implementations and feel that this particular VM is as limited as
only looking at the bytecodes for #ifTrue: but not other uses of
blocks.

> > Even as it is today, if you look at things like #perform: or proxies
> > using "message not understood" you can see that subroutines don't
> > fully explain what is going on (sorry if I got these selectors wrong
> > - I have been programming mostly in Self, lately).
> 
> #perform: isn't very special. It's just the same as (eval ...) in Lisp.
> But nobody ever claimed that subroutine calls should be named
> differently in Lisp.
> A similar thing goes for proxies. It would be easy to beef up, say,
> Basic to include an OnUnknownSubroutine handler. It would require some
> library stuff to give that handler enough information so that it can
> reissue the call in the appropriate context, but nothing of this is
> particular to Smalltalk or messaging.

You are missing the point entirely! There is a concrete representation
of a message (class Message). This is like an email exchanged
between two objects, and its existence is *very* important even
if the implementation can effectively eliminate it 99.99% of the
time.

Without reified message objects, you need "library stuff to give that
handler enough information so that it can reissue the call in the
appropriate context". Adding this to Basic will give it a very poor
version of message passing, so I can't agree that this is not
particular to messaging.

Please note the huge difference between:

      Compiler evaluate: '3+4'  "this like like eval() in Lisp"

and

      (Message selector: #+ argument: 4) sentTo: 3  "this is not!!"

Actually, the #sentTo: method (which I think should be called
#sendTo: instead...) just unwraps the message components and calls
#perform:with:.

I admit we are doing a very poor job of explaining this difference
to you, and why messages in Smalltalk should be thought of being the
same as kind of thing as messages in Occam or actor languages (and
so need to use the same names).

Speaking of names, I no longer think of a method as the analog of
a subroutine. Instead, I think of the set of methods that implement
a message as the equivalent of the subroutine in a imperative
language.

-- Jecel