On the role of Schedules in Swarm...

[Chris G. Langton]

The role of schedules in the overall scheme of Swarm.....
-----------------------------------------------------------

Turning to why the Swarm machinery that you have is the way that it is....

A good deal of the machinery in Swarm is there to support interpreted 
SCHEDULES of message calls on objects efficiently - it may seem cumbersome
now, but there are very good reasons for working with dynamic schedules,
and there will be a suite of high-level tools that will make the process
of creating, altering, and manipulating these schedules much easier than
it is now.....

Recall that:

        a) provide users with the capability to create artificial worlds 
                populated with complex sets of interacting agents, spatial 
                dynamics, and instrumentation tools, and also 

        b) (more importantly) to provide users with the capability to 
                interact in a general purpose way with these artificial worlds 
                at run-time, creating/executing/analysing, and even altering 
                the components of both the world and the experimental 
                setup.

Thus, we are trying to provide an interactive experimental workbench for 
complex multi-agent systems, with whose components the researcher can 
interact in real-time, just as he/she would interact in real-time with the 
components of a "real" physical experiment.

This means that we have to provide a computational environment that 
separates out the functions of 

        a) creating the objects in the world, and
        b) manipulating those objects.

The creation part of this is not difficult - the basic object oriented 
programming paradigm takes care of that aspect pretty well. 

The more difficult part to do in a general purpose and interactive way is 
the manipulation part. 

This is where SCHEDULES come in. Much of the effort on Swarm has been 
in the kernel's support for the dynamic management of schedules of 
events over collections of objects.

In our approach, "schedules ("Activity-plans," "Activity trees," "action-
plans,"etc.) are data structures containing method calls on instances of 
objects. The data-structure philosophy in Swarm is that data-structures 
are objects that know how to create "iterators" over themselves. Thus, 
Schedules know how to create "schedulers" that will iterate over the 
data-structures containing sequences of method calls on objects, 
invoking those methods on those objects. 

Why should we make the users go through the trouble of building data-
structures containing method calls on objects??? Why not just let them 
put such calls directly inline in the code and have them compiled (a tip 
of the hat to Ginger Booth for her example of this distinction in her 
intro-message to the new beta-folks..... ;-) ).

Because, for the flexibility we require in the way in which events are 
managed over the instances of objects in the Swarm worlds, the 
schedules of events must be dynamic and changeable, and therefore 
must be in the form of something that is *interpreted* at run-time, 
rather than compiled in advance. 

In truth, one could perfectly well use the Swarm machinery with inline 
method invocations embedded in while-loops, avoiding schedules 
altogether. However, we believe that schedules provide an *extremely* 
powerful and simple vehicle for interacting and experimenting with 
artificial worlds, so we have spent a lot of effort to provide machinery to 
interpret schedules efficiently. Also, we will be providing higher-level 
tools to create and maintain schedules, so, in the near future, users will 
not have to plod through the current brute-force machinations to build 
these schedules....

We expect that the majority of the use of Swarm in the future will be to 
create objects with little or no compile-time construction of schedules of 
events over those objects. The user will have tools to build and manage 
sequences of events over those objects interactivelly at run-time. Also, 
the creation of the objects themselves can be managed interactively at 
run-time via these dynamic schedules. In fact, even the "code" that 
individual agents execute can itself be represented by dynamic schedules 
of sequences of method calls on objects, allowing the rules that agents 
invoke to change and/or evolve over time. (In fact, in the long run, we
are aiming at a general purpose programming language built entirely
on method calls on objects...but that's a later story....).

So - we have spent a lot of time on the mechanisms for supporting the 
management of schedules. Schedules can be concurrent, embedded in 
one another hierarchicaly, conditionally executed, and the mechanisms 
for constructing and altering schedules are available to the software 
agents themselves. The latter capability allows the objects in swarm 
worlds to dynamically alter their own schedules or the schedules of the 
worlds in which they live. This implies that sophisticated swarm agents 
can themselves build and experiment with swarm simulations, and may 
ground their actions in their "real" world on the basis of the outcomes 
of their simulated worlds.

Most of the higher-level tools to access these capabilities will come
into place within the next several months. We plan to have such tools
as well as a much more fleshed out library of useful simulation and
analysis objects by the beginning of the summer, when we plan to 
release version 1.0....

In the longer-term works, we will be aiming for a parallel version of
the kernel in Swarm version 2.0, which we are hoping to be beta-testing
starting some time in the summer....

Anyway, we are turning our attention now from the low-level computational
primitives of swarm to the higher-level user-interface and simulation 
tool libraries...please bear with us, as your experience with the low
level primitives will help us determine what higher level pre-packaging of
low-level functionalities will be useful and/or necessary...

So - suggestions for useful tools are welcome, and contribution of
tools to help flesh out our libraries are especially welcome.....!!

Cheers!

Chris Langton