Visual LISP, AutoLISP and General Customization

Visual LISP, AutoLISP and General Customization

Reply
Active Contributor
ynotrobits
Posts: 36
Registered: ‎05-31-2009
Message 1 of 11 (548 Views)

Lisp theory question on setting variables to nil

548 Views, 10 Replies
03-21-2012 01:28 PM

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.

*Expert Elite*
azrdgldr
Posts: 1,250
Registered: ‎01-09-2007
Message 2 of 11 (537 Views)

Re: Lisp theory question on setting variables to nil

03-21-2012 02:53 PM in reply to: ynotrobits

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

*Expert Elite*
scot-65
Posts: 2,181
Registered: ‎12-11-2003
Message 3 of 11 (528 Views)

Re: Lisp theory question on setting variables to nil

03-21-2012 03:56 PM in reply to: ynotrobits

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

 

???

Scot-65
Dyslexia is a permanent physical disability that cannot be seen.
Introverts is proof that there is indeed intelligent life on this planet.
*Expert Elite*
dbroad
Posts: 1,585
Registered: ‎08-16-2007
Message 4 of 11 (521 Views)

Re: Lisp theory question on setting variables to nil

03-21-2012 07:37 PM in reply to: ynotrobits

[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.

Active Contributor
ynotrobits
Posts: 36
Registered: ‎05-31-2009
Message 5 of 11 (508 Views)

Re: Lisp theory question on setting variables to nil

03-22-2012 09:33 AM in reply to: ynotrobits

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

Active Member
beaufordt
Posts: 10
Registered: ‎03-25-2009
Message 6 of 11 (492 Views)

Re: Lisp theory question on setting variables to nil

03-22-2012 11:49 AM in reply to: ynotrobits

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. 

64bit AutoCAD Map & Civil 3D 2013 Infrastructure Design Suite 2014
Windows 7 Dell Xeon 3.2 Ghz 12GB Novell network
Mentor
stevor
Posts: 855
Registered: ‎12-26-2005
Message 7 of 11 (471 Views)

Re: Lisp theory question on setting variables to nil

03-23-2012 07:11 AM in reply to: ynotrobits

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 .

S
*Expert Elite*
Kent1Cooper
Posts: 5,534
Registered: ‎09-13-2004
Message 8 of 11 (469 Views)

Re: Lisp theory question on setting variables to nil

03-23-2012 08:06 AM in reply to: stevor

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.

Kent Cooper
Active Contributor
ynotrobits
Posts: 36
Registered: ‎05-31-2009
Message 9 of 11 (464 Views)

Re: Lisp theory question on setting variables to nil

03-23-2012 09:54 AM in reply to: ynotrobits

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.

*Expert Elite*
dbroad
Posts: 1,585
Registered: ‎08-16-2007
Message 10 of 11 (449 Views)

Re: Lisp theory question on setting variables to nil

03-23-2012 03:01 PM in reply to: ynotrobits

>>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.

Need installation help?

Start with some of our most frequented solutions or visit the Installation and Licensing Forum to get help installing your software.