On July 4th, 1996, ccr version 0.1, the second major prototype
developed for the project, stood at revision 88, and comprised some 63K
lines of C, another 11K lines of Tcl, about 1K lines of ccrl, and
another few K of perl, makefiles, shell scripts, and the like.
Though small compared to where it needs to be, version 0.1 is already
quite rich---possessing, for example, a fairly well-developed
computational and communications model, and, in jargon, a multiple
inheritance runtime extensible persistent object-oriented interpreted
language with incremental network object and type cache updating, the
GUI-based world ccrTk, and the text-only ccrt.
Version 0.1 speaks a scripting and programming language called
ccrl that mediates communications between a ccr
world and its environment, which consists principally of humans, other
ccr worlds, files, and spawned subprocesses. ccrl
is more akin to an application scripting language or an
object-oriented MUD programming language than to a conventional
development language, in that it developed out of and in tandem with
ccr. Using ccrl, users can significantly revise the
functions of and extend the type system that a ccr world is
Rudiments of the object hierarchy
The core library of ccr v0.1.88~~ defines 352 object types.
There is as yet essentially no offline documentation, but just to
stimulate the imagination, a sampling of the 0.1.88 object hierarchy,
selecting just representative types, and multiplying out multiple
inheritance relationships where included, could look like this:
|-->Primitives--> Int, Float, Objid, Box, String, List, Vector, Type, etc.
|-->Root-->Struct--> Method, Reviser, TimeV, Trace, UDPPacket, etc.
|-->Interprocess--> Challenge, Response, IPHello, IPPing, IPLink, etc.
|-->Matter--> Channel, UDPSource, UDPSink, etc.
| |-->Item--> Body, Button, File, Place, Variable, Xproc, etc.
| |-->Sarq--> Process, Pulse, Quit, SWave, MailRoom, etc.
| | |
| | |-->Link--> Body, Door, Maildrop, Soul
| |-->Container--> Cave, Place, Vlist
| | |
| | |-->Place-->Space-->Door, Room
| |-->Force--> ForeignLegion, Reader, ccrSelf, Soul
|-->Function--> Bail, OfferNet, CancelNet, Rationalize, etc.
| |-->OKFunction--> Abs, Not, BinOp, DefType, Eval, RXMatch,
| | Identify, TypeOf, UDPSend, When, etc.
| |-->QFunction--> And, Let, If, While, Progn, DefMethod, etc.
|-->Energy--> TimeOut, LinkProtocol, Now, Rat, MailSend, MailAck, etc.
|-->GodEnergy--> Unbind, DrawSpace, LogHistory, etc.
|-->ReadEnergy--> Describe, CacheLoad, ReadRefspace, etc.
|-->WriteRefspace--> Bind, BindReq, Stub, etc.
|-->Verb--> Bump, Clear, Click, Close, Enter,
| Input, Look, Push, Read, Reset,
| Shove, UDPReceive, etc.
|-->Emit--> Beep, Be, Decide, Do, Hail,
| Have, Pose, Think, etc.
|-->Say--> Answer, Ask, Whisper, etc.
Notes on selected object types
- The Act is the most general object capable of
altering the state of the system -- loosely speaking, an act is like a
`message' in traditional object-oriented programming terms, or like a
`function invocation frame' in a conventional stack-based programming
language, but unlike either, Acts are first-class, allocated objects.
(They are not persistent, however; that is what Matter is for.)
Acts fall into two subclasses: Functions and Energy. Functions can be applied to any type of object,
whereas energy can only be applied to the object id
of a piece of matter. Functions typically complete atomically and
return an object as a value, while energy typically runs
asynchronously and generates further acts rather than directly
returning a value.
- A body is capable of moving around, and in
particular, it is the only object type allowed through
conventional network Doors to thereby move from
ccr world to ccr world. A body is linked to a soul, relaying an event stream back to the soul and
emitting energy sent from the soul.
- The object :ccr in each ccr
world is of type ccrSelf, and it holds information about that world,
including its public and private keys (the latter stored encrypted
with the user's password, and also marked as a ::Private
slot, so the cache management system will never ship it offworld), the
version of the code, information about the hardware, and so forth. As
of v0.1.88~~, it also includes an optional `PublicHTMLPath' slot to
indicate a pathname for writing out status information to the web, as
the ccr central key server does in the ccr central status page.
- In the ccrTk graphical interface world,
certain mouse clicks are (necessarily) visible to the refspace -- for
example, to operate a publicly-accessible button in another ccr world.
Click energy mediates such actions.
- The semantics of a specific ccr
world can be altered and extended by locally-defined methods created
with DefMethod. Although locally-defined object types (created by Deftype) must be broadcast to the refspace to allow
remote ccr worlds to render them properly, locally-defined methods
remain resident on and private to the defining machine. The to-date
still vaporware network package system is destined to provide a means
for transmitting method definitions in a coherent and risks-revealed
- New object types can be created by
subclassing one (or several) existing object types. Created types are
persistent and are demand-downloaded to remote ccr worlds as instances
of the locally-defined classes enter a remote world's refspace.
Foreign type definitions are cached with the data objects of the world
that defines them and are not commingled with local data or types. In
particular, it is not possible to create a local instance of a foreign
- Along with bodies, doors
are the most user-visible type of link. Doors mate
up in East-West or North-South pairs, and provide the main
spatial mechanism for joining hierarchical structures together
- Energy objects are acts
that are always `at' some piece of matter, though
as an energy `propagates', it typically visits several pieces of
matter. Loosely speaking, energy divides into two subclasses: `read energy', which propagates entirely within
the ccr world in which it was generated (perhaps visiting cached
copies of foreign world objects while it does), and `write energy', which propagates through the
network physically to visit remote world objects, if any such objects
are in the refspace of the source of the energy.
- In ccr, only forces are permitted to build objects
and perform acts, and the force that created each act
is carried with the act as it propagates. The majority of acts within
the system require a local force to function; an object of
type ForeignLegion exists to perform certain acts on behalf of
non-local forces while maintaining usage records.
- Below the ordinarily
user-visible network interactions, inter-ccr communications are
mediated by the exchange of Interprocess objects. Such object
transmissions perform functions such as checking that the remote ccr is
still alive, and trading high-level usage and latency information
(IPPing), ensuring that no extraneous messages have been injected into
the communications channel (Challenge and Response), initiating the
process connection protocol (IPHello), setting up MailDrops to
exchange ccr email msgs (IPLink), and so forth.
- Energy generally
propagates hierarchically, up from items to the containers that hold
them, and down from containers to their contained items, but link
objects are the exception. Links cause a point-to-point propagation
from one link to its `link mate' whenever an energy object reaches an
open link. Crucially, the mate of a link can be in a different ccr
world. Via links, individual ccr worlds weave themselves into the
fabric of the ccr universe. A Body wandering out
on the network is linked one-to-one to a soul which
never leaves the homeworld. A door links to another door (on the same
or a different world), creating passageways for bodies to move.
- Objects of type matter have
network-unique object ids, and are persistent: Once
created they remain across program restarts until the connection
between the object id and the matter is destroyed via Unbind. As a
general design principle, as much as possible of the user-visible
program state is stored as matter to provide continuity, including,
for example, window positions and sizes, command and focus histories,
and error messages.
- An object id is a unique network-wide name
for a piece of matter, including the IP address and port number of the
ccr world that owns the name.
- The offernet command is built on top
of the ccr email system, and is used to offer a doorway to a specific
other ccr world. Both worlds must explicitly issue an offernet naming
the same door pairing, but either world can unilaterally issue a
cancelnet command to destroy the link.
- Named in homage to the great lineages of MUD
development, pose energy propagates an arbitrary descriptive phrase to
refer to the soul that generated it. As of ccr v0.1.88~~, pose text
can include HTML2.0 tags.
- The process object represents one ccr
world's knowledge of another ccr world. The `Known Worlds' entry in
ccr central status page, for
example, is the count of process objects in that world that have
public keys stored with them. In addition to maintaining static
information like the remote world IP address and port number, the
process also maintains incremental information such as the total
communications traffic between the worlds, and dynamic information
such as the links that are currently open between
the two worlds.
- In the land of distributed
computation, there are ever so many ways to screw up! The
perfect ordered domino trails of Von Neumann machine computation are,
at best, a hopelessly inefficient approach in large-scale distributed
systems. Recognizing this, ccr expects that every type of
object within the system will provide a method for the `Rat' energy,
and when that method is invoked the object will perform a
self-consistency check and take whatever steps are necessary to bring
the object to a consistent state, perhaps propagating Rats to touching
objects in the process.
Although, in principle, there is always the possibility of `runaway
Rat loops' between objects -- ``I say this, you fix
yourself!'' ``No, I say this, you fix yourself''... -- in
practice so far it has proved relatively easy to find one or more
natural `ground states' for object collections to terminate Rat
propagations. For example, a `soft ground state' for a mated pair of
Links is the link is closed; a `hard ground state' is the link is
Rationalize repeatedly propagates Rat energy to each object in the
local world until all objects report no changes, or a specified number
of passes have been performed. Rationalize is performed automatically
at system start up, but can be requested while the system is running,
as sort of an `online fsck'. When run online, it is possible
that occasionally an object will be caught midway through a protocol
exchange and will appear to be inconsistent to the Rat method, and the
Rat method will rationalize the object, and whatever was in progress
will likely fail to perform as desired. But so what? The system is
designed to expect things to screw up nearly arbitrarily, and to keep
on functioning anyway.
- Since local ccr worlds keep
cached copies of accessible objects from remote worlds, there is a
natural distinction between acts that only examine
data, and acts that intend to change data, since the latter acts must
actually reach the world that owns the data to have a chance of
affecting it. ReadRefspace energy access the local cache and perform
no network traffic, and are used for tasks such as drawing the
refspace in the ccrTk view window, finding the relative
position of an object in the refspace, or simply enumerating the
refspace for some other purpose.
- The basic workaday container that users are
most familiar with. Because it is a Container, it can hold Items;
because it is a Space, it has two-dimensional extent and constrains
its contents to a bounded region.
- The basic means of talking, as well as the base
class for more specific modes of talking such as whispering,
exclaiming, answering, and so forth. The ccrl parser translates all
input lines that do not begin with `[' into some kind of a Say: An
Exclaim if the last character is `!', an Ask if the last character is
`?', and a plain Say otherwise. This has the side-effect that a
leading space can be viewed as a comment character in ccrl program
text, causing ccr to speak the `comments', but do nothing else with
them, as the program text is read.
- The `invisible end' of a body link. The soul
is in charge of parsing keyboard and pointer events from the god of
the ccr world, drawing the soul's refspace in the view window (in
ccrTk), shipping emitted energy to the body, and `unparsing' the
event stream received from the body into the soul's ongoing ccr life
A subtlety often confusing to new users of ccrTk is that the
image that is displayed in the view window at the location of a body
is actually stored on the soul, not on the body. This apparently
poetic `face is the mirror of the soul' design decision actually
arises from basic and concrete concerns: Once the body goes off the
home world, the home world god essentially loses write access
to the body, while the god of the world the body visits essentially
gains total power over it. Placing the `face' on the soul
allows the soul owner to control it directly, rather than having to
play kind of `Mother may I smile' games with the current
owner of the body. More experienced ccr gods see bodies
basically as place-holders indicating that its associated soul is in
- Many of the basic actions that users --- and
ccr worlds themselves --- perform are verbs, with a `object'
indicating what is to be affected, a `subject' saying who
requested the action, a `tense' indicating whether the verb is
currently a `request' (present tense) or an `event' (past tense), and
a `result' describing how things turned out (if the verb is an
event). A Verb such as Say propagates from the soul
to the body in the present tense. Once it reaches the body (assuming
it does), the verb `succeeds' and a past tense copy of the verb is
repropagated from the body. It is (almost entirely) the stream of
past tense verbs arriving at the soul that comprises the ccr life
story of that soul.
- Unlike ReadRefspace energy, which can complete locally
using cached copies of remote objects, WriteRefspace energy are
designed to side-effect the state of the ccr universe in some way, and
consequently they must propagate through the network to reach their
targets. Just about everything that `does something', in a
simple-minded sense, is WriteRefspace energy. Note that in complex
refspaces (e.g., multiple netdoors off a single room), a WriteRefspace
object may actually propagate through multiple machines before having
its final effect.
Ackley, D. H. (1996, to appear).
- ccr: A Network of Worlds for
Research. In Artificial Life V, MIT Press.