Daron, now I'm not entirely sure about this but... (Smadsen, do you know for sure?) When you create a variable name associated with the value of "nil" you are doing two things; One allocating space for a variable and two, destroying it. So as I see it, the variable 'c' is created and destroyed. By telling the interpreter that we are defining a new variable named 'c' we are telling it to allocate memory space for it, but then when we assign it to a value of 'nil' that tells the interpreter to destroy it. So the 'c' variable is nothing more then a flash in the pan.
Se7en, consider this example of indirect assignment:
(setq a 4.0) -> 4.0
!a -> 4.0
no mystery
(setq b 'a) -> A
!a -> 4.0
still no mystery
(set b 'a) -> A
!a -> A
Oops, mystery starts
(set b 10.0) -> 10.0
!a -> 10.0
Huh?
Of course there's no mystery at all.
B is assigned to the symbol of
A and can therefore be
SET without being quoted (it's already quoted). Because
B points to
A it assigns the value 10.0 to
A. A simple case of indirect assignment.
How does that relate to your question about destroying a variable by setting it to nil? Well, if you set
B to nil - and by doing that is setting
A to nil indirectly - are you destroying
A?
B will still point to
A!b -> A
Does it mean that
A has fallen off the face of the earth?
In the old days (when McCarthy invented the stuff), an atomic symbol held a definition called a property list. The list described various things such as the name, the type and the value of a symbol - e.g. SUBR pointers if it was a function name. Until the new LPP/Vital LISP engine took over, the XLISP-based AutoLISP had some clues as to the same principles - e.g. a symbol name would occupy one more cons cell if the name was longer than 6 characters.
If that scheme is still true I have no idea whatsoever. But if it is then it should mean that symbols are not destroyed by simply being assigned a value of nil - it would just mean that they are made ready to be swept up by the next garbage collection (if not referenced by other means).