It should be noted in this example that the pushes and pops only really push down to the next level and then pop right back up. They never get any deeper unless this code somehow becomes recursive. The dot level has an implied QUIT that pops the stack each time it gets pushed down. Recursion is something else. It actually will halt the execution on the stack to re-execute the same code again from the new stack level. Now that can go nearly 1,000 levels deep (or more if the stack space is adequate).
----- Original Message ----- From: "Gary Monger" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Saturday, February 11, 2006 9:08 PM Subject: RE: [Hardhats-members] KILL'ing and NEW'ing -- what's really happening? The DO inside the loop will create 1000 pushes and 1000 pops. The NEW will push VAR 1000 times. Its usually better to NEW outside the loop, and use SET/KILL inside the loop if you need to reset. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Sunday, February 12, 2006 12:02 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] KILL'ing and NEW'ing -- what's really happening? ... > When you "NEW" a variable, you basically create a fresh variable with > the same name, that shadows the old value until the DO block or > extrinsic call exits and the variable name is again associated with > the old storage location. Think about it this way: your environment > consists of a stack of structures called frames. When you perform a > DO, you allocate a new frame and push it onto the stack. When you NEW > a variable, you allocate a fresh storage location and add it to the > current frame. When you exit the DO block, the stack is popped and > the "NEW" variable disappears. So in this code for i=1:1:1000 do . new VAR . set VAR=i Then the frame containing VAR is popped/discarded at the end of each loop, because the do block has concluded, right? We don't get 1000 pushes onto the stack, right? Thanks for you help. Kevin ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
