On schedules....

[cgl]

  The main purpose of the Swarm architecture is to support 
model composition.

  We wanted to build a framework in which a "model" can be viewed
as a building block that can be composed with other models to form
a larger model. On this approach, everything is a "model", and
complex models are built from simpler models.

  In order to do this, we have to be able to compose both the
things in models *and* the event-structures over those things.
This is why we separate out the event-structure over things
in the form of schedules. The activity machinery has the smarts
built in to merge event-structures of models to form the
event-structure over the composite model. In turn, this
composite model can be composed with other composite models
by merging their event-structures once again at a higher level,
and so on.

  Thus, the majority of our work on Swarm has been on the
activity machinery so that it will support a wide variety of
different event-scheduling schemes (especially various
schemes for handling concurrency) while maintaining this
composability of event-structures.

In the composition of models, the composition of objects
is straight forward: objects can contain other objects.
However the composition of events over those objects is
not so straight forward, and has taken us a considerable
amount of effort to work out in a general but efficient
way.

  The schedule machinery in Swarm is certainly not the only
way to make event-structures composable, but it has proven
to be a worthwhile scheme to pursue to implementation so
that it can be evaluated in a wide variety of event-management
situations. So far, we are very pleased with its flexibility
and generality, although it has not proven easy to explain
or to implement in a way that makes the event composition
functions obvious or straight forward. We see it as a
major open task to make this event composition machinery
more accessible and understandable to Swarm users. 

The event-structure machinery (the activity functions) can
seem particularly confusing when a user is only building
a simple model, thus not invoking the event-structure
composition machinery - making the whole schedule apparatus
seem like major overkill. However, we feel that as we 
begin to understand the power of the event-composition
machinery, we will begin to view and implement our
models out of "finer-grained" models, whose components are
more reusable in a larger variety of contexts - something that 
has not been easily possible before because there was
no general machinery for model composition. 

  Thus a "Swarm" is a dynamic, model building-block, containing
both things and events - it is a complete model in itself, but
is structured so that it can be composed neatly and seamlessly
(that's the goal anyway) with other model building blocks which
are "complete" in themselves as well. A Swarm model consists
of lots of autonomous, dynamic models behaving in each other's
presence, and the event-composition machinery is the "magic"
that makes it all go through....

  Another reason for separating out the event-structures as
objects in their own rights is to allow the event-structure itself
to emerge during the course of the simulation, rather than to
have to specify it in advance. In a sense, a dynamically emerging
event-structure is another "model" - one that captures the 
structure of the future (and records the structure of the past).
These "models" of event structure can then be observed, analyzed,
reasoned about, modified, and etc, either by the modeller
or by the agents in the model themselves, if appropriate.

 At the moment, Swarm users need to work directly with the
low-level event-composition machinery - essentially dealing with
the Swarm virtual parallel computer at an "assembly language"
level. Our next major task is to package these low-level
activity functions up in higher level functions, which will
hide much of the low-level machinations that users have to
concern themselves with now. Of course, we had to implement
the low-level machinery first, before we had anything to
package up, and we are still gaining experience on what
the higher-level functions should and/or could be. Suggestions
(ala Manor's recent one) are welcome.  Also, we have to do a much 
better job of documenting the functions that users currently have 
to deal with.

  Another major task is to make the composite model structures
more accessible and examinable by users. We will do this by
implementing graphic browsers/editors for both composite event-structures
and composite object hierarchies, so that users will be able to
view the structures they have composed directly and manipulate
and/or edit them.

  Ultimately, we would like to implement a visual programming
language on top of Swarm, which will allow models to be composed
by clicking on model-icons and composing and linking
them together "manually" (mouse-ually?), but this may be a
bit down the road yet.

Chris Langton


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================