Scratch

Consider this piece of Scratch:

<forever>
<broadcast[ a
<end>

<when I receive[ a
<change{ x }by( 1

Now it works, but only because of a bug I posted in previous post.
This is how it works:

Let us run a <forever>

Step 1:
Broadcast puts new <when I receive[ process into a list, then step ends.
Processes in list are: 1st <forever> in line 2, 2nd <when I receive[ in line 2

Step 2:
Broadcast puts new <when I receive[ process into a list, stopping previous one.
Because of a bug, the stopped one gets to run, then step ends.
Processes in list are: 1st <forever> in line 2, 2nd the new <when I receive[ in line 2
The old <when I receive[ gets pruned out.

Step n: the same as step 2.

Now, if you consider what I posted before as a bug and fix it, this code will not work, because <when I receive[ process never get to run.

Now I may finally come to what I wanted: to suggest slight policy change. It was inspired by this:

<when green flag clicked>
<forever>
<change{ x }by( 1
<end>

<when green flag clicked>
<forever>
<broadcast[ a ]and wait c>
<end>

<when I receive[ a
<change{ y }by( 1

If you run it, you see that the ratio of x:y is 3:1 (which I considered too much, I would accept 2:1). The reason is, the newly added processes go to end of the process list,
so in step 1 broadcast is done and new process is added to the list, in step 2 first the wait is processed (which fail since new process did not get to run), then the new process adds 1, and in step 3 we fall through wait and yield on forever body end.

The policy I suggest is let the new processes get their chance first. That is, either collect them to new collection or remember how much there were before adding (no matter, impl details), but when there is the final select: at the end of runStepFor:, let the new processes come first, and the old ones second.

This would make the ratio 2:1, and would solve the previous bug as well. And it seems to me more logical, anyway. It's just that the list is now cyclical, in effect, so order will not get harmed.

Last edited by deerel (2008-08-26 16:26:50)