On Feb 11, 2006, at 7:55 PM, Kevin Toppenberg wrote:
OK. Bad example.
Not really.
Here is a closer one to what I am working on.
...
new Array,done
set done=0
for do quit:done
. kill Array
. if $$UpdateInfo(.Array)=1 do SOMETHING
. (more logic here)
. set done=(some logic)
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. Now, each frame has a pointer (called
the dynamic link) to the frame that was active when it was created
(let's call it the parent). Now, if you reference a variable, such as
Y in
SET X=Y+2
then the interpreter consuls the current frame looking for a variable
named Y. If none is found, it follows the dynamic link, attempting to
find Y in that frame, and so on, until Y is found, or there are no
more frames, at which time an error is signaled. If you enter a DO
block and NEW a variable, a fresh storage location will be allocated
in the current frame, and the old value of the variable will be
stored in the new location. When the block is exited, the frame is
simply discarded, and so you have the old value back, and any changes
you made to the new value are gone (which is what you want).
So here we have Array NEW'ed outside the loop. Array is used
primarily as an OUT parameter from function UpdateInfo(). The
function may be called repeatedly unto the done= logic is satisfied.
I want to ensure that there are not residual data in Array from the
last cycle, so I kill Array before the call. But I want to be able to
use the Array later outside the loop.
There's really no one answer here. I don't like the way reference
parameters work in MUMPS, but that's another story. You can put your
changes into a new variable and MERGE it into the old one, you can
KILL values you don't want to remain in the area, or whatever you
feel most comfortable with.
So my question was the status of the symbol table when I had NEW'd a
variable outside a loop, and then KILLed it in the loop. I wondered
if any prior values were popped off the storage stack etc.
If you KILL it within the loop but do not NEW it within that loop,
then you are KILLing the fresh copy of the variable that you created
with the NEW. The effect of the KILL will not be visible after the
enclosing block (not the loop) exits.
It helps to think of a variable as a name that is associated with a
storage location containing a value. There are two things that can
change during execution of the program: one is the value stored at a
given location and the other is the storage location associated with
a variable name. Remember also that these variables all live on the
runtime stack. This is different from languages such as C, where
variables can live on the heap or the stack. Globals provide the
closest analog to heap, except that globals are shared among
processes but, say, a static variable in C will not be.
Kevin
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."
-- Antoine de Saint-Exupery
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
