Hi Rob --

At 6:58 PM -0800 11/16/03, Rob Withers wrote:
>Alan, your hint did the trick.  I keep forgetting that
>Smalltalk is based on the simpliest of ideas.  We have
>objects and messages.

Actually objects and message-sending (since messages are also objects) ....

>   If objects have no "state",
>only references to other objects, then it's all
>messages.

It's worthwhile contemplating that most bits in computers are dynamic 
relations between processes, so "state" is really a kind of process 
.... Quite a few of the ideas in Special Relativity on "how one knows 
about things going on" apply to these ideas.

>   The power is not the stuff, it's what's
>between the stuff.

The Japanese call this "ma".

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

The first one I did for Smalltalk in Sept '72 is pretty small (less 
than a page). There is a sketch of it in one of the Appendices of the 
"Early History of Smalltalk" paper. It was influenced by the Lisp one 
on the bottom of page 13 of the Lisp 1.5 manual (but I did ST-72 
assuming a nonrecursive base to make it a little more as though it 
were running on a conventional machine). Dan Ingalls did a brilliant 
job of making it really real. This could be quite a bit smaller if 
done a little differently.

>  We could implement addition of
>SmallIntegers as a table lookup, and have no bytecodes
>or primitives.

Think about what true and false are in Smalltalk. And what objects 
are. You can easily synthesize arithmetic without needing any tables.

>  I would want to use it to help me see
>all the way down to the bottom.

This is always a good idea. For Smalltalk-80 though, I'd recommend 
the beautiful version (using byte codes) in the Appendix of Dan 
Ingall's '78 POPL paper on Smalltalk-76. This is a pretty neat one 
pager.

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

That's the frame. The algebra is the choices of "polymorphisms" in 
the base design.

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

Not really in the sense of Smalltalk-72. But the E-systems ideas 
greatly illuminate much of this area. Interestingly, the first use of 
"capabilities" that I can identify is actually in the hardware of the 
B5000 described by Bob Barton in 1961. This is pretty amazing 
thinking for any decade in computing, let alone 4 decades ago.

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

The term "fields" here is used differently. And the compact form of 
Maxwell's equations as we know them today is due to Hertz, who used 
"operators" like div, grad, and curl to collapse many separate 
differential forms.

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

My notion is that computing is a new kind of math, and we are best 
off when we use classical math and science as inspirations and for 
analogies, but not try to be too slavish about fitting computing into 
classical forms.

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

As I mentioned, several OSs (such as MUSE/Aperios, etc) have 
experimented with this idea. And Sketchpad is certainly the first 
system I've seen that deals with constraints as though in a physical 
space.

Cheers,

Alan

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


--