Visual LISP, AutoLISP and General Customization

[#1]

Hello all,

I was curious: In the back of my mind there is something that says that in Lisp, one should set variables back to nil when they are no longer needed. For example:

(Setq V1 5)

(Do stuff with V5)

(finish with V5)

(setq V1 nil)

(go on to do other things)

Do I gain anything by using the above tactic as opposed to placing the variable inside the switch at the beginning of the Lisp:

(defun c:MyLisp (/ V5)

Or is this something that was necessary when computers had less available memory and is no longer applicable today?

Thanks for looking.

[#2]

Look into the differences of local and global variables and use the one that best suits your needs.  HTH.

[#3]

If you do not declare "V1" in the defun, it becomes a loose gremlin

that *might* interfere with (your) other third-party programs.

It is a good habit to declare these, but optional to clear them at the end of the program.

I personally clear them at the end of the program. I also clear them in the local error handler.

As an example, I want to show a dialog box the first time a program is run, but do not

want that dialog to show on successive calls during a particular editing session.

This calls for a "flag" to be set, which, in turn is a gremlin. The structure I use for this

is "USER_ProgramName". This item is not shown in the defun section.

(defun c:XYZ ()

 (if (not USER_XYZ)

 (progn

  (setq USER_XYZ 1)

  [show alert box]

 );progn

);if

[do stuff]

(princ)

);end

???

[#4]

[quote]Do I gain anything by using the above tactic as opposed to placing the variable inside the switch at the beginning of the Lisp:[/quote]

No.  Local variables are generally a better approach.  Garbage cleanup is automatic.

If you  need to store data between function executions, name the symbols uniquely so that it is unlikely to be overwritten (example:  providing prompt defaults).

If symbols are used in certain loops, then the garbage collection of the loop will clean them up automatically.

(Example:  (foreach n ....)  The n will not need to be set to nil and it does not need to be declared locally.

Many situations where a setq is used can be rewritten as nested function calls.

For certain situations involving activeX objects, it has been recommended that those objects be released.  I have found that declaring those variables local is generally sufficient.

[#5]

Thanks for the answers. Yes, that was my question: Whether or not I gained anything by dumipng the local variables into the "garbage" earlier during the program via nils or waiting until the end of the run to have them dumped automatically.

Thanks

[#6]

You don't have to worry about conflicts with local variables.  If Var is set to 55 globaly and you set it locally to 30 even if you crash or hit escape before the routine is complete Var will be 55 afterwards.  In a properly error proofed routine the *error* should be localized as well. 

[#7]

One possible reason to Not make them local variables would be to check their values, their contents, after the routine closes. That would conflict with the global variables that are intentionally global. In that case, setting them to nil would not preserve the values of the intended globals either;  they would have the last contents that was set.

So, often global variable names are made with special  features, like an '*' or a '_' etc; to avoid the accidental overwriting .

[#8]

---

stevor wrote:

One possible reason to Not make them local variables would be to check their values, their contents, after the routine closes. ....

---

I sometimes do that, while I'm developing something, this way:

(defun C:Whatever

  (/ *error*); varA varB varC); list ready, but temporarily not localized

  (setq varA nil varB nil varC nil); temporary for testing purposes

  (defun *error*

    ....
 

That way, each time I test the command, it wipes those values clean to start, which has the same effect as if they're localized for its internal purposes, but they remain set after I've run it.  So if it doesn't work right, I can look at variable values until I find one that doesn't exist or is wrong somehow, and narrow down where the problem is.

After it's working right, I just take out the ); in the variables list to make those variable names local, and remove the line below that sets them all to nil.

[#9]

Boy, that final answer was definitely woth the post. Thanks, that' ssomething that will come in handy as of today since I'm troubleshooting right now; Greatly apprecciated.

[#10]

>>After it's working right, I just take out the ); in the variables list to make those variable names local, and remove the line below that sets them all to nil.<<

Or just comment out the line with the nils for future testing.  I sometimes use this technique but have found that with "break on error" active, if an actual error occurs, then the local values remain on the break, even those declared local.  Testing lines one by one by selective loading or by setting breakpoints and stepping can also be used in lieu of temporarily commenting out the local variables. 

The advantage to this is that "reset to top" restores the global variables that might have been wiped out during testing. This is done after "break on error" stops execution.  "Go to break point" is also useful for errors.

>>Boy, that final answer was definitely woth the post. 

Alas, no kudos or chili donuts awarded to any contributor.