> A message in Smalltalk (the current Smalltalks, anyway) returns
> values, so from the perspective of the sender this is like a
> "subroutine". The sender does not know how the value will be computed,
> but the sender does know a value will be returned even if it is just
> the reference to the receiver. (Or there will be an "exception".)
> 
> OTOH an asynchronous message send could be more general. There may or
> may not be a response some time later. The response may or may not
> come from the receiver and it may or may not go to the sender. This is
> more general because it can be used to build the more restrictive
> mechanism, not vice versa.

Various rambles:

There was an interesting book called "Programming Language Linguistics"
which talked a bit about Smalltalk.  It called the phrase "object-oriented"
tacky, noting that to orient means to point in a certain (eastwardly :-) 
direction.  It also said that the phrase "send a message" wasn't quite 
right since usually one doesn't think of sending a message as implying a 
returned response.

Also, in Smalltalk, one could view 'thisContext' sorta like a 
continuation, with ^-returns being an optimized message to thisContext,
that moves the locus of control back to the receiver.  Exceptions, then,
are just more cannonicalizations of thing you could do to thisContext;
things that are less common than ^-returns, but better than being totally 
ad-hoc.  Viewed this way, Exceptions are "exceptions to the normal flow 
of control" rather than "exceptional (unusual) conditions"

I approach message sending in Smalltalk similar to the way I view the
Class/Metaclass design.  It does the job 99% of the time, and gives
you the hooks to do what you want the other 1% (well, really just the 
other 0.99%, that's why we need to hack the VM).  Sending to thisContext,
like creating non-ClassDescription behaviors, is the 1% trick.

Speaking of all this stuff, and thinking about ma:

	To understand ma, debug the debugger, and see how
	it does a send.

	Likewise for the VM.

	It would be nice to have a simple, clean meta-circular
	evaluator for Smalltalk.  See SICP, ch4.
	basic plan:
		Scheme       Smalltalk
		(read ...)   Parser
		s-expr       ParseNode tree
		(eval ...)   SomethingLikeInstructionClient
		             but based on ParseNodes, not byte-codes
		environments Contexts
	This meta-cicular interpreter would be good for playing
	with different ma's

	The SqueakTeam has already done a nice job on SICP ch5.

	Ma is what's between the sender of a message, and the receiver.

	I'm reminded of a Bob Welch song: (Danchiva)
		Think about the place behind your eyes 
		Then think about the darkness, when you turn out the lights
		Think about the space between the notes
	
	http://cyberpenguin.net/penguin/lyrics/d.htm#danchiva

-- Mike Klein