Animas are objects that provide an interface to the background execution facility of LiveWorld. An anima causes its enclosing object to be sent messages repeatedly. Animas run concurrently with user actions and provide the underlying ability to create autonomous and reactive objects. Animas are the foundation on which the agent systems of Chapter 5 are built.
When the animas are running, all objects containing active animas are sent :step messages repeatedly. Any object can have a :step method, but they are most commonly found in method objects. The effect of sending :step to a method object is to apply the method to its container. A method of zero arguments can thus be converted into an agent of sorts simply by dropping an anima into it (see Figure 4.9 for an example). Animas are thus conceptually similar to processes, although the execution of animas are not truly concurrent (Chapter 5 goes into more detail about how animas can be modified to provide better concurrency as well as conflict resolution facilities). The execution of animas is interleaved with each other and with user action.
Animas may be turned on or off individually, and there is also a "master switch" in the LiveWorld menu that can disable all animas. When this master switch is off, the entire system can be single stepped by the user, which means that each active anima gets sent a single :step message. This is useful for debugging.
It is interesting to note that the metaphorical description of the relationship between processes and procedure is inverted. In more traditional systems, processes are established that execute procedures inside themselves, while in LiveWorld, the process mechanism lives inside the procedural object that it calls. This inversion of the usual relationship is one part of LiveWorld's attempt to change the metaphors used to describe computation into a form that suggests a greater degree of animacy and autonomy (see Chapter 3).
LiveWorld defines some slot objects that are specialized for particular kinds of values, such as colors or points, that have special display requirements. The prototypes for these objects live in a library named #/slots (see Figure 4.10). For example, #/slots/color-slot defines special methods that cause it to display its value as a color swatch, and to invoke the system color picker when its value is edited. These slots are incorporated into other system objects (i.e., most actors have a color-slot, and turtles and some sensors use an angle-slot to specify their headings).
Figure 4.10: The slot library.
Some specialized slots take advantage of Framer's recursive annotations to have parameters of their own. In the figure, bar-graph-slot and formatted-slot are open to show their parameter slots.
Computed slots are slots that dynamically compute their value from an expression, in the manner of spreadsheet cells. The value of a computed slot is defined by a to-compute method defined as an annotation to the slot. For example, the computed slot area in Figure 4.11 computes the area of its containing actor as the product of the actor's regular xsiz and ysiz slots. Note the use of boxpaths in the method, which allows the area slot to be cloned into other actors.
Figure 4.11: An example of a computed slot.
A computed slot's value is accessed using normal mechanisms, but trying to set it will cause an error. The value is displayed in an italic font to indicate that it is not settable. There are actually several varieties of computed slots. The simplest just computes its value on demand (that is, whenever the rectangle is asked for its area, the multiplication specified in the to-compute method will be run). The more complex varieties cache their value and only recompute it when necessary. This requires that the cached value be invalidated whenever any of the values that it depends upon change. Since these values are in other slots, this can be accomplished by putting demons (see 4.5.5) on the depended-upon slots which invalidate the cached values (a technique developed in (Fisher 1970) to support what were called "continuously evaluating expressions"). These demons are installed automatically by monitoring slot accesses during the evaluation of the to-compute method.
Figure 4.12: The same computed slot, with the internal slots
that comprise the computational mechanism revealed.
Figure 4.12 illustrates some of the internal structures and mechanisms that implement computed slots. Every cached computed slot has an internally stored value and a flag that specifies whether or not that value is valid. Each slot upon which the computed slot depends has a demon added, which causes the computed slot to become invalid whenever the value of the depended-upon slot changes. In this case the demon appears as a compiled Lisp closure.
Figure 4.13: Inside a triangle-sensor.
Figure 4.14: The sensor library
Sensors are objects that allow actors to obtain information about their surroundings, and are implemented specialized versions of computed slots. That is, they are computed slots that compute their value based on the actors' world, and are designed to be annotations of actors. Sensors can also provide a graphic representation of themselves as an add-on layer to the actor they are part of. An example of a sensor may be seen in Figure 4.3. This triangle-sensor is so called because its field is in the shape of a triangular region, and is sensitive to objects that enter that field. Sensors make particularly effective use of Framer's hierarchical representation structure, which lets them be seen as both slots and objects with slots of their own. Sensors contain slots that specify their parameters or details about the results they are computing (the to-compute method can set other slots besides returning a value). An example is shown in Figure 4.13. Shape is a computed slot itself, that depends upon field-heading, field-width, field-range, and on the heading of the containing actor. The effect of these dependencies is to let the shape of the sensor be computed automatically when the actor moves or when the user changes the values of one of the sensor's slots. Other parameters allow the sensor to be customized to be sensitive to particular kinds of objects (for instance, only ovals).
There are many kinds of sensors (see Figure 4.14). Some, like the triangle-sensor, have a predicate value. Others have numerical values (for instance, the range-sensor, which monitors the distance of a single object) or return the detected actor or actors themselves (such as nearest-object-sensor). While most sensors respond to actors, some, like wall-sensor, respond to other features of the environment.
LiveWorld's object system makes it straightforward to provide specialized objects for a variety of media, and also to provide libraries of samples. The two most useful and most fully supported media forms are pictures and sounds. Pictures are simply a form of actor. Sounds are specialized boxes with :play and :record methods. Both pictures and sounds objects are implemented as encapsulations of the corresponding Macintosh system objects, and can be imported from external applications.
Figure 4.15: Libraries of pictures and sounds.
Sound objects can be used to provide auditory responses for creatures or sound effects for games, but also have a special use for debugging, a technique sometimes called "program auralization" (DiGiano, Baecker et al. 1993) by analogy to the well-established techniques of program visualization.
LiveWorld supports audioization by providing a special kind of object, called an auto-sound, which can be dropped into a method. The effect of this is to cause the sound to be played whenever the method is called. This technique not only supports program audioization, but makes it easy to add sound effects to games and simulations.
Frames can also be used to implement a form of memory loosely based on Minsky's K-line learning mechanism (Minsky 1980). In Society of Mind, a K-line records a partial mental state represented as the activation state of a set of agents. In LiveWorld, a K-line can record the state (that is, the values) of a selected set of boxes. A K-line is a box created in the usual way. To specify that a slot is to be recorded by the K-line, the user makes a clone of the slot and drops it into the K-line. The K-line thus contains spinoffs of all the frames that it covers and responds to two basic messages, :store and :recall, which have simple implementations. Store forces each spinoff to have the current value of its prototype, while recall copies the value of the spinoff back to the prototype. An additional message, :add-object, will cause the K-line to cover all of the interesting slots of an object. LiveWorld's K-lines were constructed mostly to see how far the prototype relationship could be extended into other uses (for a similar experiment, see the discussion of ports in 4.9.1). While these K-lines are not powerful enough to be of much use in mental modeling, they have proved to have some utility in recording initial states for applications like animations and games.