Event-Oriented Computing

[glen e. p. ropella]

So, with all the jabber about JINI and the BDI people talking about
modeling cognitive agents in stark contrast to .... oh, agents with more
tightly coupled behavior and implementation, something is beginning
to congeal in my mind.  I thought I'd run it by you guys just as a first
sanity check.

It was pointed out on another mailing list I'm on that Larry Yeager
characterizes the programming effort at Vivarium as "Event-Oriented
Computing".  He goes on to talk about JINI-like things like 
discovery and lookup of available resources.   It occurs to me that 
one of the things Swarm lacks is a kind of base-space.  We talk about
it being able to instantiate discrete-event, continuous time, or hybrid
simulations and we talk about it being able to instantiate *any* computational
process because the agents are implemented via a generic programming
language.  We've even tried to talk about what the scheduling machinery
and the object definition modules are all about in the sense of an 
event *language* or a structural *language*, respectively.

But, what we don't really talk about is, if we really can instantiate 
*agents*, in the strongest sense of the word, then how is it (by what
underlying mechanism) an agent goes about exploring her world?

Right now, most Swarm programmers don't particularly care about this.
They just explicitly install rules for communication between one object
and another (the agent and its "world").  But, with the kind of deeper
functionality that Swarm and the tool chain on which it is based offer,
we could implement agents that explore the GNU, ObjC, Swarm, and
application structure, which would be a kind of exploration of their
natural environment.  (You people who actually know this stuff should
correct me if I'm wrong.)

If we could put sensible lower bounds on what our agents can explore
(i.e. define the primitives below which we really don't want application
writers to think about), we could provide more of a complex system
experimental engine and pull Swarm from this "modeling toolkit"
sink it's stuck in.  As I understand it, Swarm wasn't intended as JUST
a modeling toolkit, although that goal is worthy in itself.  It was also 
intended as a kind of pond in which you toss things that have the potential
to learn to exploit their environment.  So, if we think LESS like gods
who want (or have the obligation to create) explicit control over what
goes on in our applications and MORE like children who will throw 
a snake into a fish tank just to see what it'll do.

Does anyone else think this way, or am I alone?

Anyway, it strikes me that Swarm has the potential to be pre-adapted as
an Event-Oriented Computer, as I imagine Larry's describing, if and only
if we can develop the mechanisms for agents to explore the computational
space in which we place them.  This would mean a) picking a line to draw
in the tool chain (do we let agents have access to the OS, the GNU-specific
functions, the ObjC infrastructure, etc), b) abstracting the mechanisms
we want to allow agents to use (like getClass, for example), and c) publishing
a kind of discovery and lookup API for Swarm so that users can begin
to use it.  In this way, *any* agent that adheres to a certain kind of
interface
can be tossed into *any* Swarm application at any time to wreak havoc.

I can imagine tossing a BugPoker into the Heatbugs app that wanders around
examining each bug or the regions of the space, instantiating probes, and 
randomly poking a bug or the space so that bugs get teleported to other 
places for no reason.  Or it could *eat* the bug and replace it with a 
carcass that didn't respond to the messages sent to it by the scheduler.
Etc.

glen

--
glen e. p. ropella                =><=          Hail Eris!
Home: http://www.trail.com/~gepr/home.html  (505) 424-0448
Work: http://www.swarm.com                  (505) 995-0818  


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================