Kevin: Ah, how simple a question you ask. The answer, or rather an attempt to frame a response could fill volumes. The discovery of the issues relating to the 'KILL' command was a persistent debate in the MUMPS Development committee during the entire time I participated in that organization, from the mid 80's into the 90's.
The KILL command is a 'primitive', 'elementary' method that destroys a binding between a symbol and an associated data value. By custom this means also that the 'symbol' and the 'data', the two things joined by the binding are expunged from the system as well. So, not only does the binding 'disappear', but the things themselves are 'deleted'. KILL is the eraser on the end of the #2 pencil. (However, there are implementation specific effects that follow a KILL command that may leave some influence of the past presence of bindings. Thus, in some systems in the past, over the life a a specific instance of a MUMPS process, the LOCAL SYMBOLs (bindings) storage space would decrease, and eventually become unusable.) Now, enter the NEW command. ...and, with it a flood of problems, with some precious crumbs of useful functionality. Of most interest in the context of your example, the NEW command alters the 'visibility' of bindings. NEW also has the ability to influence a SET of bindings, a set designated by an explicit LIST of symbols, or implicitly determined. The NEW command moves one or more bindings from the local symbol table of the current process onto a storage stack associated with that process. The bindings in the local symbol table for that process are then deleted as though a KILL command had been performed on those 'newed' bindings. (The term 'delete(d)' is used in the M standard in the definition of the KILL and NEW commands, and is a term that is not further defined.) So, the bindings are 'erased' from the local symbol table, but these bindings are preserved in the process stack. Eventually, if you want them back, these bindings can be recovered into the local symbol table. The intention of the NEW command design process was to provide MUMPS with some form of 'variable scoping'. Good intentions notwithstanding, the design of the NEW command took a wrong turn in the 'heat of battle' in the MDC and we are left with a poorly designed language feature. That you are obliged ask this question signals the weakness of the NEW feature. That I can't provide a decent answer to your question is in part due to the overly complex, implementation dependent nature of the NEW command. I have never mastered the NEW command, certainly due to my own limitations, but also due to the way the MDC designed it in the first place. AT the risk of being insensitive, Kevin, I think that you are best advised to expend some effort studying the M standard, and doing some experimentation with your M system. Coming to the point of understanding in which you can answer your own question is likely to be the best way to determine the answer to this question. "....beware Greeks bearing gifts." :-) Regards, Richard. -- Richard Davis Mformation SYStems Company tel: 508-869-6976 fax: 508-869-6008 e-mail: [EMAIL PROTECTED] > From: Kevin Toppenberg <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Sat, 11 Sep 2004 13:41:48 -0700 (PDT) > To: Hardhats Sourceforge <[EMAIL PROTECTED]> > Subject: [Hardhats-members] Mumps question: What is difference between Kill > and New? > > Hey all, > > Quick Mumps question. I have a loop like this: > > ------------------- > MyFunct() > > new MyVar > > Label1 > kill MyVar ;<---- should this be new MyVar? > set result=$$Func2(.MyVar) > > goto Label1 > ------------------- > > I want to ensure that any old data from a previous > loop is cleaned out before calling Func2. Should I > use 'new' or 'kill' each time? What is 'new' really > doing? Allocating memory? If so, then I don't want > to repeatitively use up memory. On the other hand, if > I use kill, then I think I would get an error trying > to pass a non-existant variable. > > Thanks > Kevin > > > > _______________________________ > Do you Yahoo!? > Shop for Back-to-School deals on Yahoo! Shopping. > http://shopping.yahoo.com/backtoschool > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Hardhats-members mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
