[Translation] Engendrando un smalltalk
dfarber at numenor.com
Wed Feb 12 22:35:49 UTC 2003
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 found.
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 specific instant.
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 inside it.
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 gestation.
The parent has a SystemDictionary [Smalltalk] that defines the World (global names).
What do we need to generate a seed/embryo?
1. A SystemDictionary [microSmalltalk] that defines Globality in the embryonic world
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 MicroObject.
Possible definitions: nil subclass: #microObject ...
[Parent] Object subclass: #MicroObject ... (where Object is not in the MicroSystemDictionary!)
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 gestation.
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 world
(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 necessary.
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 stability.
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 them.
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 children!
Could it be a virgin Smalltalk?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Generating Smalltalk.doc
Size: 128000 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030212/3f815d21/GeneratingSmalltalk.doc
-------------- next part --------------
dfarber at numenor.com
More information about the Squeak-dev