At 21:31 02.05.2002 -0400, Bijan Parsia wrote:
>My question is that if you mutate a patch inside the block argument to
>#patchesDo: are you promised that the next patch evaluated will see the
>"old" state of the world?

I'm afraid not, no.  In the current scheme, any patch or turtle mutations 
will indeed be visible to all following demon code.

>If the patches in a world are supposed to be executed *in parallel*, then
>the fact that we are actually evaluating them sequentially shouldn't
>affect the results.

You're right.  The current implementation goes for a simpler, "one 
blackboard" model.  I've found that my simulations could be adapted to that 
if I kept the following guidelines in mind:

* Consider the patch identities immutable (they don't even exist, 
really).  Mutate patch variables instead.  Use patch color for environment 
(eg. soil) and patch variables for environmental parameters (scent, light, 
food that doesn't move itself :-), etc).

* For stuff moving/disappearing/appearing (and changing) from one cycle to 
the next, use turtles.  Turtles have identity, and demons can mutate their 
instance variables.

* Turtle demons are run first (in random order) on a *snapshot* of the 
turtles currently alive.  Turtle demons will only be triggered for the 
current population regardless of how many turtles have been added/deleted 
by demons already.

* World demons are run (again, in random order) after turtle demons.  They 
see any patch effects that the turtle demons may have caused.  Depending on 
how they look at turtles (see cache below), they may or may not see turtle 
effects caused by the turtle demons.

* Turtle access by patch position is cached (per cycle).  The cache is 
filled on first access, and invalidated after all demons have run.  Thus, 
after the first positional access, dead turtles (that got sent #die) are 
still in that cache, new turtles aren't yet.

To take StarSqueakLife as an example:

One turtle demon, #live, examines the neighboring patches (via cache) and 
increments (!) the #neighbors patch variable there (for the world demon, 
s.b.), and decides the turtle's fate depending on how many neighboring 
turtles it saw.  It could #die safely, as it's ghost is still in the cache 
(for others to count).

One world demon, #giveBirth, walks all patches and detects empty patches 
where #neighbors has an accumulated value of 3.  It creates a new turtle 
there, but does not look at or mutate neighboring turtles or patches -- 
this preserves the "parallel execution illusion."

So... Maybe you can apply the turtle cache in a similar way?

>Nothing I see seems to make this so. I would think some sort of
>"currentState/nextState" setup would be needed, with #get: pulling from
>the currentState and #set: setting into the nextState.

Sounds reasonable if your simulation requires it.  You'd have to preserve 
the old patchForm (a Form) and the Dictionary of patchVariables (Bitmaps), 
copy new ones, and switch after completing the demon runs for a step.  That 
might affect the frame rate a bit, but who knows.

HTH,
Helge