Alan, your hint did the trick.  I keep forgetting that
Smalltalk is based on the simpliest of ideas.  We have
objects and messages.  If objects have no "state",
only references to other objects, then it's all
messages.  The power is not the stuff, it's what's
between the stuff.

This must mean that all the bytecodes are to support
running on top of a stack machine and to speed up
common message sends.  The Squeak compiler's targets
this stack machine with its generated bytecodes.  

I have often wondered what the world's simpliest
Smalltalk evaluator would look like, with no vm, just
an eval loop.  We could implement addition of
SmallIntegers as a table lookup, and have no bytecodes
or primitives.  I would want to use it to help me see
all the way down to the bottom.  Lisp books typically
have these kinds of examples.

The real eye-opener, for me, is that the complete
algebra for this system is just the msg send, isn't
it?  That is the only computation within this space
that takes place.  What had drawn me to Mark Miller's
E-rights was their idea that a msg send can ALSO be an
eventual msg send.  My erratic attempts at bringing
this into squeak made me think this is a fundamental
change to Squeak.  If I am understanding correctly,
this changes the fundamental algebra of the system. 
Do you think this the case?

Then I re-read your first response:

> >>  Originally, algebra was a symbolic form of
> >>  arithmetic. In the 19th
> >>  century, mathematicians realized that there were
> >>  lots of other
> >>  systems that had some of the properties of
> numbers,
> >>  and they gave
> >>  such systems with various overlaps to numbers,
> names
> >>  such as groups,
> >>  fields, rings, etc., and algebras. This then

This work must have been closely related to the work
by Maxwell on EMFs, since they needed the math to
describe the fields.

It also struck me that we currently view Squeak as a
system of groups (with nested groups and atomic groups
- stateless, like the number 7), and the foundational
recursive relation is the msg send.  Would you say
that other ideas in this thread are trying to make our
system more like a system of fields? ...and I use that
term non-rigorously, not really knowing what a
field-based algebra is defined. 

In order to dovetail back to the original topic, the
notes from Diego and Marcus are talking about
receiverless msgs and more biological analogies.  I
would really like to see some analog to the endocrine
system in the substrate of squeak.  Perhaps that is
similar to Marcus' message strength, and is certainly
like StarLogo.


Thanks!

Rob

--- Alan Kay <Alan.Kay at squeakland.org> wrote:
> Hint: as I mentioned previously, you don't need a
> method dictionary, 
> classes, inheritance, etc. You don't even need
> "state" in the way it 
> is usually thought of. The essence is that of
> communicating computers 
> as looked at from the outside. If you can make the
> insides look like 
> the outsides "all the way down" then you have
> something very 
> interesting and powerful.
> 
> And yes, the original theory of Smalltalk was just
> this (since even 
> the syntaxes used are definable by interior actions
> of how the 
> "computers" recognize and receive messages). The
> interesting and 
> difficult parts here are design decisions about
> architectural 
> conventions that allow the universal mechanisms to
> be used with 
> minimal pain and maximum expression and scalability
> by humans.
> 
> Each of the 4 Smalltalks in the 70s made different
> choices (plus the 
> PIE system of Goldstein & Bobrow), and it's a pity
> that there have 
> been so few experiments since Smalltalk-80 came out
> of PARC.
> 
> But check out some of Mark Lentzner's stuff:
> Codeworks, Wheat, etc. 
> Look at Joe Goguen's ideas about closer analogies to
> algebras as the 
> interface, etc. Ken Kahn's various designs over the
> years are 
> extremely interesting. Several of the designs I did
> after leaving 
> PARC -- Rainbow, and the original Playground (quite
> different from 
> each other and I'm not sure where either set of
> papers is anymore) -- 
> still seem to be interesting to me. David Reed's
> NAMOS is the basis 
> of Croquet. And, of course, Andreas Raab's not too
> far away Tweak 
> design is a *really interesting* set of ideas....
> 
> However, there have been many interesting ideas over
> the years that 
> have had little effect because they lacked enough
> pragmatic reality 
> via great implementations (and certainly vice versa:
> an incredible 
> number of systems used today have weak ideas but
> were implemented 
> well enough to spread).
> 
> Cheers,
> 
> Alan
> 
> At 9:42 AM -0800 11/16/03, Rob Withers wrote:
> >Hi Alan,
> >
> >--- Alan Kay <Alan.Kay at squeakland.org> wrote:
> >>  Hi Rob --
> >>
> >>  At 6:19 PM -0800 11/14/03, Rob Withers wrote:
> >>  >Alan, these posts are always so stimulating. 
> Could
> >>  >you tell me a little about abstact algebras and
> how
> >>  >you relate them to computers sending messages
> to
> >>  other
> >>  >computers?  Is it related to defining
> languages, in
> >>  >some way?
> >>
> >>  Originally, algebra was a symbolic form of
> >>  arithmetic. In the 19th
> >>  century, mathematicians realized that there were
> >>  lots of other
> >>  systems that had some of the properties of
> numbers,
> >>  and they gave
> >>  such systems with various overlaps to numbers,
> names
> >>  such as groups,
> >>  fields, rings, etc., and algebras. This then
> became
> >>  a useful metaphor
> >>  and goal: to try to find common properties of
> >>  systems and abstract
> >>  them into the simplest schemes that covered all
> of
> >>  them.  So, e.g, a
> >>  number of the object-like systems I saw in the
> 60s,
> >>  such as
> >>  Sketchpad, used a particular offset in the
> layout to
> >>  find the pointer
> >>  to (say) the display subroutine for that kind of
> >>  object. Today we
> >>  call that polymorphism, but this term is
> borrowed
> >>  from theory of
> >>  functions and is not quite right. In any case,
> once
> >>  you have an
> >>  inside and an outside, and try to do everything
> >>  through embedded
> >>  procedures of some kind, you have set up the
> >>  possibility for an
> >>  "algebra" of meaning that could extend over all
> >>  objects. Clearly, a
> >>  good job of this cuts down the size and
> nomenclature
> >>  of the concept
> >>  space. This thinking was before APL, but not
> before
> >>  Iverson's book
> >>  that defined a more comprehensive version of
> APL,
> >>  and it occured to
> >>  me that you could go much further than Iverson
> did
> >>  with what I called
> >>  "generic procedures".
> >
> >We have a system of objects in an image, and there
> is
> >an algebra defined for these objects.  These
> objects
> >can be transformed by "primitive" operations.   Is
> our
> >algebra defined by the Interpreter, both it's
> >bytecodes and msg lookup mechanism?
> >
> >So there must be an extended definition of what is
> an
> >object in this system.  An object has identity,
> state
> >and a class, with a method dictionary filled with
> >procedures.  Then all functions are recursive in a
> >sense, due to the fact that they can invoke any
> >primitive operation or recurse with another msg
> send
> >to any visible object.
> >
> >It has nothing to do with Smalltalk, the language. 
> We
> >can have any number of languages describing
> functions
> >in this algebraic system!  Wow!  I feel like I am
> >starting to get the mathematical underpinnings of
> what
> >we really have here.
> >
> >>
> >>  >
> >>  >you also wrote:
> >>  >
> >>  >>  An interesting consequence of this structure
> was
> >>  >>  that protection was
> >>  >>  complete in ST-72, and all messages could be
> >>  >>  serialized if the object
> >>  >>  wanted (we did not bother with this because
> we
> >>  were
> >>  >>  working on
> >>  >>  different kinds of problems -- but Hewitt
> >>  thought
> >>  >>  about it a lot).
> >>  >
> >>  >Could you say a little more about why
> protection
> >>  was
> >>  >ensured?
> >>
> >>  In the very same way that a computer on the
> Internet
> >>  is quite
> >>  intrinsically safe -- no outside entity can
> force
> >>  anything because
> >>  the computer has to run some of its own code
> before
> >>  anything can be
> >>  admitted and acted upon. To hurt a computer it
> has
> >>  to have stupid and
> >>  foolable SW. The ST-72 objects were only given a
> >>  pointer to the
> >>  message and the knowledge that a message was
> trying
> 
=== message truncated ===