unintern a symbol vs set to nil
Xah Lee
and later i want to delete the var, i can do:
(setq temp1 nil)
or is it better to do
(unintern 'temp1)
The temp1 var holds a big list, and there are few more, e.g. temp2,
temp3.
(if i use “let”, that means few hundred lines inside it with other
lets.)
Thanks.
Xah
Alan Mackenzie
Xah Lee <xah...@gmail.com> wrote:
> in a elisp program, if i have created a temp var (but not using let)
....
As a matter of interest, how do you do that?
> .... and later i want to delete the var, i can do:
> (setq temp1 nil)
> or is it better to do
> (unintern 'temp1)
Shouldn't much matter. Probably better to set it to nil, because that's
more usual. OTOH, if you want to detect an error should temp1 be
subsequently accessed, then uninterning it will be better.
> The temp1 var holds a big list, and there are few more, e.g. temp2,
> temp3.
Either approach will allow these lists to be garbage collected.
> (if i use ?let?, that means few hundred lines inside it with other
> lets.)
> Thanks.
> Xah
--
Alan Mackenzie (Nuremberg, Germany).
Xah Lee
hey Alan. thanks for the answer. (per your question, it's just a
normal var i call it temp.)
Xah
Stefan Monnier
>> or is it better to do
>> (unintern 'temp1)
IIRC I already in earlier discussions pointed out that unintern is to be
used with extreme caution when handling symbols that are interned in the
normal obarray.
> Shouldn't much matter.
It matters a lot. `unintern' will not do what he wants.
A general rule could be: if you did not intern it yourself, never ever
unintern it unless you actually know what you're doing.
> Probably better to set it to nil, because that's more usual. OTOH, if
> you want to detect an error should temp1 be subsequently accessed,
> then uninterning it will be better.
Alan, I think you're confusing unintern with makunbound. He can use
makunbound if he wants.
>> The temp1 var holds a big list, and there are few more, e.g. temp2,
>> temp3.
> Either approach will allow these lists to be garbage collected.
Actually unintern instead of setq-nil could prevent the list from
being GC'd. But it's probably the least of your concerns.
>> (if i use ?let?, that means few hundred lines inside it with other
>> lets.)
`let' is the right way. If the result is ugly, change the rest of the
code (e.g. make a bunch of functions out of those hundreds of lines).
Stefan
Tim X
A lot depends on what you are using these 'tmp' variables for and
whether you are concerned about memory and gc or namespace pollution. If
they are defvar variables you only use when debugging/developing, then I
wold be tempted to define a 'debug' var and put them inside a (when
*debug* or something similar (though I tend to avoid that approach and
prefer using various custom functions and macros I've written to assist
in debugging). If on the other hand, these are variables used to hold
temporary calculations/state etc that is part of normal processing, then
I'd set them to nil and would never use unintern.
The one definite I would state is that if the only reason you are
defining these temp variables as global defvar rather than inside a let
is because it makes the let ugly or too large, then I'd suggest you are
emphasizing the wrong things. Apart from polluting your namespace with
unnecessary symbols, you are also creating potential
problems/conflicts/bugs. Variables should only be defined with defvar
when absolutely necessary and not for convenience or misguided asthetic
reasons. If the let looks ugly, then factor the temp stuff out into its
own function that can bee called from within the let (or any of numerous
other possible solutions).
Would also suggest you never use
(defvar tmp1 ...)
in emacs either. If you must use defvar, prefix the variable with
something unique, such as the package/filename or even xah-tmp1. This
will reduce the likelihood of creating a global that conflicts with a
variable of the same name in somebody elses package. Doing so can also
make debugging a lot easier (try debugging a problem with w3m, which
does not follow this convention). Using package/person specific prefixes
also helps to make sure that when writing some elisp and you do an
apropos etc to find a function/variable that you want, you can easily distinguish
between core emacs functions/variables and ones added by packages you
have loaded (which may not always be loaded/available).
Tim
--
tcross (at) rapttech dot com dot au
Tim X
Hi Stefan,
very useful to know. While I've never found a need to use unintern as
suggested above, I certainly was not aware of the potential dangers of
doing so. Good to know.
Alan Mackenzie
>>> (setq temp1 nil)
>>> or is it better to do
>>> (unintern 'temp1)
> Alan, I think you're confusing unintern with makunbound. He can use
> makunbound if he wants.
Yes, I was indeed getting so confused. Thanks for pointing that out.
> Stefan
Pascal J. Bourguignon
> Hi, Xah.
>
> Xah Lee <xah...@gmail.com> wrote:
>> in a elisp program, if i have created a temp var (but not using let)
> ....
>
> As a matter of interest, how do you do that?
>
>> .... and later i want to delete the var, i can do:
>
>> (setq temp1 nil)
>
>> or is it better to do
>
>> (unintern 'temp1)
>
> Shouldn't much matter. Probably better to set it to nil, because that's
> more usual. OTOH, if you want to detect an error should temp1 be
> subsequently accessed, then uninterning it will be better.
Not at all. (Yet some other fodder for Xah's idiocy articles, sorry).
(defvar temp1 42)
(defun f ()
temp1)
(unintern 'temp1)
(f) --> 42
>> The temp1 var holds a big list, and there are few more, e.g. temp2,
>> temp3.
>
> Either approach will allow these lists to be garbage collected.
Wrong. See above.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Xah Lee
> Not at all. (Yet some other fodder for Xah's idiocy articles, sorry).
you mean my articles describing idiots like you?
Here's a juicy passage of Pascal J Bourguignon fellow, in which you
can get a glimpse of his highness:
«Ruby's been done by some Japanese newbie... I guess there was some
language barrier preventing him to learn from the 50 years of
occidental experience in programming language design. At least, he
wasn't a "linguist"... In any case, why should we suffer for THEIR
incompetences?!?»
Xah