[Translation] Engendrando un smalltalk
Alejandro F. Reimondo
aleReimondo at smalltalking.net
Thu Feb 13 14:47:24 UTC 2003
Thank you David!
>Y que es un "condón umbilical"? Ya que hay un cordon
> umbilical es un poco tarde usar condon, no? ;)
Mi MsWorld spell checker thinks that "condon"
is a more popular word; then it must be "condon".
----- Original Message -----
From: "David Farber" <dfarber at numenor.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, February 12, 2003 7:35 PM
Subject: [Translation] Engendrando un smalltalk
Here is a rough translation of Alejandro's paper "Generating Smalltalk". And
I do empasize /rough/. It should be at least marginally better than what the
automatic translators will give you, though. Attached is the same document
(with the original drawings) as a Word Doc.
Alejandro - Bueno, intente. Pero te digo que me parecio bien raro tu
espanol. ;) Talvez fue nada mas que el "voz" que se usa con temas tecnicas.
Pero, que quiere decir "se proponen técnicas de armado individual"? Y que es
un "condón umbilical"? Ya que hay un cordon umbilical es un poco tarde usar
condon, no? ;)
Alejandro F. Reimondo
The most important aspect of Smalltalk lies in what is an Object Environment
(OE). Understanding an Object Environment to be a place where things are
This permits the study of computation using manipulation techniques;
techniques that an individual has used from early on.
The understanding of this difference changes the person that uses Smalltalk
and the difficulty that some people experience learning is because,
generally, they do not expect so much from the software.
Once they understand that Smalltalk is a place, that everything is contained
in it and also related making the environment as a whole "stable"; it is
easier to also understand that these things evolve in an interactive way
attempting a general evolution of the environment.
Usually the evolution is a general improvement ...
So we have in an Object Environment a jar where we place things and watch
how they develop thanks to the interaction between ourselves or themselves.
These Object Environments are nourished by the intelligence contributed by
human beings, which they utilize and refine. The techniques of reuse and
programming permit the aggregation of intelligence in an incremental way to
the extent that it is necessary, whether aggregating new concepts and
objects or maintaining stability in general.
Since present hardware does not permit (in a practical way) an infinite
lifespan for a piece of software (at present the base is unstable and
increasingly complex) Smalltalk has used for a very long time the concept of
a "snapshot" or "image". What it manages to do is "to freeze" the whole
environment in the state in which it is found and to keep it in passive
storage, to bring it back to life later on. In this document we will use the
word "image" to mean the set of objects that makes up a Smalltalk in a
Inside an image are found a great number of objects, and it is common that
these represent various subsystems that coexist within the same world.
We define a subsystem (machine or organism) as a set of objects that are
related in an independant way; having as its most prominent property the
characteristic of existing for an interesting period of time. The subsystem
will be able to change in order to subsist.
Generally, subsystems are not independent, so changes in one system can
cause changes in others.
Also it happens that changes in one system affect the environment in which
it is found; and changes in the environment affect the systems that form it.
This wave of effects tends to diminish in intensity in time in a way
proportional to the age/stability of the environment.
The traditional method of working in Smalltalk is to begin to work from an
initial image and make it evolve until it reflects the desired environment.
Here is where one asks:
How is that initial image obtained?
The answer is simple: it is already there, you just have to copy it.
Current computing mediums have a notable characteristic, they permit us to
duplicate easily, without loss.
The inquiring person never stops asking; but ... how was the image that we
just copied obtained? And the one before that?
How was the first image obtained?
The first image was built object by object, they are told. This image had
very few objects.
Back in the 70's the first Smalltalk image was generated from a small set of
objects and then it was made to grow and grow until it became the images
that we use nowadays.
In current images there are objects that were in those first images; yes,
clearly much older and robust!
The idea is that since those days we have used copying facilities to obtain
clones of that initial image.
Each stage of the evolution of Smalltalk passed through a refinement of an
initial image, until it arrived at a degree of stability so as to be
distributed as new initial image.
The beginning generally accepted as the point of departure is cloning.
The model of propagation by cloning is a horizontal model; so that has a
high index of contagion, but prone to uncontrolled propagation. (Generally
horizontal propagation has these characteristics and never arrives at
equilibrium, save for external forces that control reproduction)
The network gives us a new medium for information propagation; the network
allows us to have a virtually infinite space.
If the image represented a World of objects, the network allows us to have a
Universe of objects.
The technique of cloning was satisfactory for individual work with an
environment of objects, although somewhat inadequate for group work.
The inconveniences of group work in Smalltalk with various worlds via the
technique of "snapshots" are known. Therefore it is common to see that
generally techniques are proposed of armed individual and joined of
subsystems (through interfaces) or the centralization of services (as in the
objects bases case with a centralized server).
How to spread Smalltalk?
We try to find a more "natural" form of generating images (worlds of
objects). By "more natural" we mean, less idealistic, more dynamic and thus
with the possibility of errors and imperfections.
We assume that, although the universe of objects is infinite, we will
continue working with Smalltalk images, with the condition that these will
be able "to reproduce" by vertical propagation (parent-child).
The idea is to generate a seed inside a Smalltalk world.
This seed [embryo] contains almost nothing, just the possibility to place
some object inside it.
As soon as we place an object inside the seed this object should try to live
In order to live (to function or whatever you want to call it), the object
must know things that are not yet found inside the seed. It must learn
things that it doesn't yet know.
The seed will be a mini-Smalltalk/mini-World inside the parent. With the
difference that it does not have anything and that everything it needs it
will obtain by being nourished by the parent.
This seed/embryo is a subsystem and to live it is nourished by (and learns
from) the parent thanks to the transparent migration of classes (methods,
etc.) from the Smalltalk parent.
Once we have the objects desired inside the embryo and it has already
"learned" all it needs from the parent (and is independant), we can to
remove it from the parent! Thus after birth it will be transformed into a
Smalltalk with ONLY what it needs to live, but having inherited the genetic
traits of the parent.
There are several interesting things about this scheme:
1. It will probably generate images much smaller and less risky than those
obtained by shrinking (trimming what is not needed).
2. We would have a way of generating Smalltalk by gestation, with
inheritance and with the concept of genetic traits inherited from the
parent! (this could possibly change our view of software, once again :-)
3. It is a tempting plan for the Internet. Not only would we have mobile and
independant images but we would also be able to encapsulate objects in mini
images that migrate from machine to machine in order to learn etc.
4. This is just the beginning.
Imagine this on web sites with the possibility of easily embedding
miniatures in mini images that are alive! A user can interact with them, to
embed them in his image or save them to disk for later user.
(Preliminary: WARNING! It is possible that this could change significantly)
The parent has the usual composition, with the possibility of generating
embryos and umbilical cords so that they can be nourished during their
The parent has a SystemDictionary [Smalltalk] that defines the World (global
What do we need to generate a seed/embryo?
1. A SystemDictionary [microSmalltalk] that defines Globality in the
2. Base MicroClasses.
3. Which classes constitute the necessary minimum set?
4. Are all the methods of the base classes necessary? [no]
5. Which methods will be necessary?
6. Micro VM kernel
9. A proxy mechanism to guarantee transparent feeding of the child.
For now (maybe this will change) I call the class Object in the embryo
Possible definitions: nil subclass: #microObject ...
[Parent] Object subclass: #MicroObject ... (where Object is not in the
Thus comes the role of #doesNotUnderstand: it transports methods from the
parent using the umbilical cord in a transparent way.
Could this be the ONLY necessary connection with the parent?
MicroWorld = MicroSmalltalk + MicroVMKernel + MicroBaseClasses
MicroSmalltalk isA: MicroSystemDictionary with the globals of the world in
MicroVMKernel = MicroVMConstants
Necessary for the operation of the virtual machine (eg. Semaphore, Process,
Point, Smalltalk etc). It corresponds to SpecialObjects in the virtual
machine. It is constant in the world that is being executed.
MicroBaseClasses = The set of classes necessary for the operation of the
(eg. Class, CompiledMethod, Symbol, Process, Context, SystemDictionary, etc)
A MicroWorld is born in the context of a world (image) parent. It is
connected the parent through a feeding mechanism in the presence of
ignorance (for example the mechanism of #doesNotUnderstand: decouples the
lookup logic in the parent through a communications channel).
As soon as it is stable and knows how "to live alone" it can be disconnected
from the parent, born by being cloned (via SystemTracer) into another medium
or into one created for it.
Feeding occurs in the face of a lack of knowledge (via #doesNotUnderstand:).
In the face of a lack of knowledge it makes a connection with the parent
(via the umbilical cord, to feed itself new methods taken from the parent).
The migration of methods from the parent generates new objects and classes
(from method literals); which lets the child accumulate only what is
The transfer of classes to the child is done through the creation of a class
in the child. The class should be created with all the methods it has so
that they can migrate in case they are needed (this is important because the
mechanism of #doesNotUnderstand: does not suffice; polymorphism in classes
of the same level).
Birth vs. Cloning
At the moment of the birth it is possible to eliminate the methods imported
but not used by the child.
Then the child can be detached from the parent.
1. The child is traversed eliminating ties with the parent (should unused
methods be deleted or should it just be disconnected from the parent?)
2. A new symbol table is constructed for the child.
3. An image is constructed by traversing the child (SystemTracer).
4. The sources are compacted.
Tools to work on the child
· Browsing the child
Should it be possible to create/modify methods in the child during
gestation? Or only in the parent. If only in the parent should the infection
of the child be immediate, defered or not done at all?
· Inspectors on the child
Should it be possible to change objects in the child via inspection? If so;
perhaps it should be compiled in the parent, migrate the method to the child
and evaluate it there.
It is not sufficient with infecting the child... Is it vile to kill the
stupid child and to create a new one?
Is infection sufficient? Isn't it problematic? It isn't [Isn't it] necessary
to have a map of transformations between the parent and child.
The transfer of objects only occurs from parent to child. No?
· To run/To simulate/To debug
It is fundamental to be able to debug the child while it is being gestated.
Possibly the simulator of the parent VM can be used for the child.
Logging in the umbilical cord would be very useful at the beginning.
Genetic propagation of traits
1. A parent is a traditional Smalltalk with the classes that know to
generate a seed, build the feeding mechanism and are sufficient to create a
complete child. The parent will contain a SystemDictionary (Smalltalk) that
defines globals, the set of classes and objects that guarantee its
2. It generates the seed, with a SystemDictionary for this and at least one
object that will be the life motive of the child environment. This prepares
the generation of classes in the child during gestation.
3. The child is born as an independant image but it can still have an
(occasional) link to the parent.
1. The father contains one (or more) object(s) that will serve as a point of
departure for the gestation of the seed. The mother has the backup for seed
generation and the basics for gestation.
2. The seed is created in the mother with objects contributed by the father.
3. The child will contain parts from the father and the mother. It might
happen that the mother does not have all the nutrients necessary during the
gestation, and she [or the child?] can communicate with the father to obtain
4. If the child contains a link to the father it will be able to be
nourished directly without using the mother.
5. If the child has various feeding links, it can decide which to use; try
in various parents or even to decide which information to feed itself (given
the several alternatives offered by the parents).
Observe that in this case the father does not need support to generate
Could it be a virgin Smalltalk?
> David Farber
> dfarber at numenor.com
More information about the Squeak-dev