More on recursion...

[Shari]

That's what I'm experimenting with right now.  I changed one of the 
most important calls by adding "send" to it, and then an additional 
(very short) time lag, just as you said.  So far the tests are good.

Perhaps traditional programming books talk about recursion in detail, 
but I've never been one for tradition.  All of my programming has 
been done in either Hypercard or Metacard, with the corresponding 
documentation.

And this is the first program I've created with the desire to 
intentionally have it keep playing with itself :-)

So you were programming before I was even thought up??

(grin)


>One observation on avoiding recursion in MC -
>
>The way this 'task1' handler is written, it cannot finish executing 
>until either 'task2' or 'task3' finishes executing, and control is 
>returned to 'task1'; in other words, this kind of call blocks 
>execution in the calling handler until the called handler finishes. 
>When you have several handlers executing each other in this way, you 
>can quickly have multiple instances of a handler in the execution 
>path, each waiting for a subsequent (called) handler to finish 
>running.
>
>You can make a small change in the way these handlers call each 
>other, so that recursion never happens. Instead of this (which 
>creates recursion):
>
>on task1
>   if the seconds mod 2 = 0 then
>     task2
>   else
>     task3
>   end if
>end task1
>
>
>on task2
>   if the seconds mod 3 = 0 then
>     task1
>   else
>     task3
>   end if
>end task2
>
>
>on task3
>   if the seconds mod 5 = 0 then
>     task1
>   else
>     task2
>   end if
>end task3
>
>... do it this way:
>
>
>on task1
>   if the seconds mod 2 = 0 then
>     send "task2" to me in 10 milliseconds
>   else
>     send "task3" to me in 10 milliseconds
>   end if
>end task1
>
>
>on task2
>   if the seconds mod 3 = 0 then
>     send "task1" to me in 10 milliseconds
>   else
>     send "task3" to me in 10 milliseconds
>   end if
>end task2
>
>
>on task3
>   if the seconds mod 5 = 0 then
>     send "task1" to me in 10 milliseconds
>   else
>     send "task2" to me in 10 milliseconds
>   end if
>end task3
>
>
>By enqueuing the execution of each called handler with a brief time 
>lag, instead of executing (calling) the called handler directly, the 
>CALLING handler always finishes running before the CALLED one 
>starts. That way, there's no way recursion can happen, even when a 
>handler calls itself:
>
>on task3
>   if the seconds mod 5 = 0 then
>     send "task3" to me in 10 milliseconds
>   else
>     send "task1" to me in 10 milliseconds
>   end if
>end task3
>
>
>I haven't tried it since about 1948 WITHOUT the time lag, but that 
>might work too. Just the act of using "send" instead of a direct 
>exec/call may break the 'execution path' so nesting and recursion 
>don't happen.
>
>Food for thought.
>
>Phil
>
>
>----- Original Message -----
>From: "Shari" <gypsyware at earthlink.net>
>To: <metacard at lists.runrev.com>
>Sent: Thursday, August 29, 2002 7:37 AM
>Subject: More on recursion...
>
>
>>  Also, does anyone know how Metacard keeps track of recursion?
>>
>>  Specifically?
>>
>>  If a handler calls another which calls another which calls the first,
>>  is this considered a handler calling itself?
>>  --
>>  --Shareware Games for the Mac--
>>  http://www.gypsyware.com
>>  _______________________________________________
>>  metacard mailing list
>>  metacard at lists.runrev.com
>>  http://lists.runrev.com/mailman/listinfo/metacard
>
>_______________________________________________
>metacard mailing list
>metacard at lists.runrev.com
>http://lists.runrev.com/mailman/listinfo/metacard

-- 
--Shareware Games for the Mac--
http://www.gypsyware.com