Summary: Neo Smalltalk groups
Last updated at 8:14 pm UTC on 30 July 2009
Reported by Jecel Assumpcao Jr
What problem is being addressed
It should be a powerful enough infrastructure to enable computing nodes to have safe local views of a virtual worldwide image. It should be simple enough so that it can be explained to, and used by, children. It should be simple for them to program something like, for example, the SqueakMap using this.
How it solves the problem
The three main concepts are objects, viewpoints and islands (previously known as groups, but renamed to be more compatible with other projects).
An object has a set of local name/value pairs and a list of parents. Unlike Self, parents are not named and have a strict order - all "slots" of the first parent and its parents come before those of the second parent. The inheritance graph is not normally cyclic like in Self. When cloning an object, you have the option of replacing one or more parents with a different object. This is a bit like setting the arguments when calling a method. It isn't quite dynamic inheritance since you then can't change the parent (of course you can always change it with reflection, but that is different). This is used for implementing "roles".
Note that Neo Smalltalk is supposed to be prototype based and has no globals at all. You can make any object point to any other through the graphical environment and you can drop any object at all into a method editor which isn't purely text based. At the bytecode level we have always had this capability in Smalltalk (any object can be included in the literal array) but there was no way to do this at the source level.
A viewpoint has a set of local island/segment pairs and a list of parents. This is parallel to the object model. An island is stored on disk as a set of segments, but in RAM is becomes a single entity. The ID for an island is the ID of the very first segment created for it. You can think of a single viewpoint as a 2D array: the rows would be the viewpoint itself at the top with the parents (and their parents) below it while the columns would be the islands. This array would be a sparse one since only some segments would actually exist. Each segment can contain a fragment of the same objects in the island: you can imagine it as extending the segments below it.
The drawing shows five viewpoints, each of which represents a different address space (process in Unix terms). The same drawing was used for all five but they would all actually be different from each other.
So an object is extended in two ways: by being the parent of some other object and by having a new viewpoint change it in some way. Note that any such changes are only visible in that viewpoint - all others would see the object as it was before. In a single computer, each viewpoint gets its own virtual machine (but might share a single screen - the GUI can do some interesting things with this). Switching between viewpoints is not a lightweight operation like in Us. Many of the examples in the Us paper should be done using roles instead. A single viewpoint can run on two or more communicating computers with a Croquet-like transaction system keeping them in sync. It is also possible to combine a viewpoint with its first parent (and recursively with any ancestor) in such a way that all changes become atomically visible to other people using that
parent in one of their own viewpoints. This would be a commit in a transactional memory system.
Segments can either be frozen or hot. Frozen segments can't be modified and have a worldwide name based on a hash of its contents. Hot segments can be added to and have temporary names. A hot segment can be frozen, but that is not reversible. A viewpoint's local segments all start out hot but its parents should only have frozen local segments. Exceptions to this require more Croquet-style synchronization and should be avoided when possible.
For a given viewpoint, an island is hot if there is a local segment for it and frozen otherwise (this should be the normal case, I hope). The VM understands the difference between hot and frozen (immutable) islands in its store and send instructions. Each hot island has a single execution thread. Like I said above, the various segments for an island are combined when reading from disk to RAM. Each island has its own object table and the viewpoint has an object table at a well known address that points to all these object tables.
Useful links
http://www.merlintec.com:8080/software/8 is a more detailed description of a previous version of this design.
http://www.merlintec.com/lsi/persist.html is a description of an even older version (mid 1990s).
http://citeseer.ist.psu.edu/smith96simple.html describes the subjective version of Self (called "Us") and some applications of multiple viewpoints.
http://www.dolphinharbor.org/dh/smalltalk/documents/ has links to the PIE documents, which talk about multiple viewpoints in Smalltalk.
Chunky Squeak is a very simplified version of this design which could be used for Squeak with little disruption, but which would need to be complemented with a proper module system.
For coherence I think the author should write the sections above this line.
People can add what they want to these later sections, and can suggest that the author change the rest.
What's cool about it
What's not
- It doesn't exist yet.
- It is being designed for special hardware and so uses things like object tables which are not efficient on stock hardware.
Commentary
Back to New Modules
