Author Topic: Variable stuffings  (Read 4173 times)

0 Members and 1 Guest are viewing this topic.

SMadsen

  • Guest
Variable stuffings
« on: November 07, 2003, 11:08:05 AM »
Quote from: Se7en
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).

daron

  • Guest
Variable stuffings
« Reply #1 on: November 07, 2003, 11:23:28 AM »
So really, nil is misleading. Am I right? Here's an example of what I mean:
(setq a nil)
!a = nil (or an empty list container, correct?)
!b = nil (Nothing was set, ever. There is no memory space for b, but it still returns nil. Why?)
That's what I think is misleading.

SMadsen

  • Guest
Variable stuffings
« Reply #2 on: November 07, 2003, 11:42:46 AM »
Yes, maybe. Nil as such is not misleading but the dynamic memory allocation may disguise the issues to a degree that seems misleading. Because nil always evaluate to nil you can't see what is actually behind the symbol of b.
In lack of proper documentation we would need a good memory dumper to get a clue of how symbols are created and destroyed.