Marcel Weiher wrote:
> 
> Joachim,
> 
> if an analogy to subroutine calls helps you in your initial
> understanding of Smalltalk, that is a good thing.  OTOH, you should
> realize that this is only an initial understanding,

I do realize that.

> that to fully understand Smalltalk and its power, you will have to
> jettison that analogy at some point.

I disagree here. I have a thorough understanding of OO in general, and
how Smalltalk implements it; and in general, OO does use normal
subroutine calls (but the subroutine actually executed is selected at
run-time, based on the object's class).
However, my understanding of subroutines is more general than many seem
to think here. In my eyes, a subroutine is characterized by its effect,
not by the sequence of actions that it contains.

> Messaging is a much more abstract concept than subroutine calls, so
> trying to understand messaging as 'subroutine calls + something' will
> ultimately fail, which doesn't mean that you cannot *implement*
> messaging using subroutine calls.

Agreed. As somebody else wrote, basically it's all Turing machines; yet
a Turing machine would be a rather bad computation model for practical
use.

> The only reason that the analogy holds at all is that Squeak /
> Smalltalk-80 uses a very specialized form of messaging, with
> assymetric synchronous messages observing a stack discipline and
> single return values.

That's what I established. Nice to hear that I understood the stuff
correctly.

> Earlier Smalltalks, including the very first Smalltalk-72 and research
> versions, used symmetric asynchronous message sends and allowed
> multiple results to be returned (that had to be picked up explicitly,
> unlike the implicit send-back/return currently in use).  These forms
> of messaging cannot easily be described in terms of subroutine calls,
> but easily fall into the conceptual framework of messaging.

Oh, these are easy to integrate into a procedural framework. There have
been many languages that had multiple return values.
The idea never made it into the mainstream, for various reasons. The
general consensus today is that you can write rather cryptic and
difficult-to-read code with multiple return codes, that it is easy
enough to achieve the same results by returning an object that contains
all the interesting data, and that they are not worth the hassle.

> As a matter of fact, some of the smoke signals I've seen coming out
> of Squeak Central seem to indicate that there is a desire to return
> to a more general message passing model in the future.

I'd be interested in seeing working, sensible design for that concept.
Hats off if they manage to do that!

Regards,
Joachim
-- 
Please don't send unsolicited ads.