Messaging vs. subroutines (Re: Thinking about a better UI)
Michael S. Klein
mklein at alumni.caltech.edu
Mon May 17 17:55:37 UTC 1999
> 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
More information about the Squeak-dev
mailing list
|