On Fri, 3 May 2002, Helge Horch wrote:

> 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.
[snip]

Yes, alas. I intend to do something about this :) It bit me because I was
trying to do a straightforward port of some StarLogo code. Ouch.

> To take StarSqueakLife as an example:

And it's a *great* example. I used it extensively in my presentation which
is downloadable from the conference site. Thanks a lot for it!

I hope to clean up the "Life Essay" a bunch and then pub it to the
SuperSwiki (or squeak news).

> 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).

Ah! I'd been wondering what the turtle cache was all able. Interesting.

> 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?

I will investigate.

> >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.

Yep. I started with a fairly naive version of this and realized that there
is code tangled all over (at least, *I* don't get all the bits yet). What
I would *like*, eventually, is to have a StarLogo-->Squeak compiler. Even
if that's slow, it's a good first step and one can always dip down in to
the hair to optimize.

> HTH,

It does. Thanks for your note and for StarSqueakLife.

Cheers,
Bijan.