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

Again, Smalltalk messaging can and does do more than that, because  
it is less specific.  For example, I don't see multicast and  
broadcast as fitting in the conceptual framework of subroutines,  but  
they're fine for messages, just like forwarding/delegation.

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

Hmm, I think subroutine is a very specific concept, distinct from,  
say, coroutine.  If your understanding of subroutine includes a  
coroutine, you might want to use a different term.

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

I am not quite sure if we're using the same definition of  
'subroutine' and 'multiple return values' here.

What I am talking about with multiple return values is multiple  
values, each 'returned' (sent-back) individually at different times,  
not tuples of return values.  This implies coroutines, which are  
quite distinct from subroutines.  I don't know of many languages that  
allow this, although there are a few (CLU, ST-72, Concurrent-ST,  
Sather, probably Simula,...).

For example, an iterator that 'returns' the elements of its collection:

contents
	self do:[ :each | ^^each ].			" ^^ stands  
for 'return but continue executing' "