(not) & maybe (null) function bug or perhaps a help document error?

[StephenCollier]

I was trying to get (null) & (not) to behave different in some way to figure out what the difference between something that is "bound to nil" and something that "evaluates to nil".  Couldn't figure it out... heheheh

But I did realize that in the case of an undefined symbol, both (not) & (null) return nil, indicating that the symbol isn't bound to nil or evaluates to nil, but if I (eval) it, it does return nil!  I tried testing them then evaluating the symbol then testing them again just in case something changed,  but I got this:

Command: (not 'bbb)
nil
Command: (null 'bbb)
nil
Command: (eval 'bbb)
nil
Command: (not 'bbb)
nil
Command: (null 'bbb)
nil

The help says (null) tests if the item is bound to nil, but the Return Values description says "evaluates".  It seems like (not) at least should return T.  I'm using AutoCAD MEP 2009.

It's probably been that way for years & none of us have needed it to check a symbol that we're not using!

Or maybe I'm just missing something about how (null), (not) & (eval) work.  After all these years, I'm only now finally properly learning about variable values, symbols, atoms and such.

[Kent1Cooper · Accepted solution]

---

@StephenCollier wrote:

I was trying to get (null) & (not) to behave different in some way to figure out what the difference between something that is "bound to nil" and something that "evaluates to nil".  Couldn't figure it out... heheheh

.... 

Command: (not 'bbb)
nil
Command: (null 'bbb)
nil
Command: (eval 'bbb)
nil
....

---

If you're talking about a variable that may or may not have a value set in it, you need to use the variable name without the apostrophe:

Command: (not bbb)
T

Command: (null bbb)
T

Command: (eval bbb)

nil

Command: !bbb
nil

With the apostrophe, it doesn't evaluate, but just reads it literally:

Command: !'bbb
BBB

[StephenCollier]

Ah, I see!

So 'bbb returns BBB which is a symbol which is something, so (not 'bbb) returns nil.

(eval 'bbb) will evaluate the value of the symbol BBB and give us nil.  In (eval bbb), bbb is already evaluated by the compiler as nil so doing the eval on it just returns nil again.  I think.  Something like that.  I think variables by themselves are usually evaluated as their value.

I think I'm getting the hang of it.  I'm trying to think of things from the compiler's point of view (wish I had gotten around to studying compilers!).  I just gotta keep track of when I'm looking at the value vs the symbol.  And what all the functions are expecting.  Ugh.

[scot-65]

Here's another good one -

I had a situation where there was a test to determine if a declared variable is not defined.

At that time I did not know what I know today to resolve this.

When the test returned nil, the program stopped.

I resolved this by using the following:

(not (not a))

...

[Lee_Mac]

Here's another fun exercise to emulate the indirect addressing behaviour of pointers found in other languages such as C++:

_$ (set 'a 1)
1
_$ (set 'b 'a)
A
_$ (set b 2)
2
_$ a
2

[martti.halminen]

- As Kent said, this would work better without the quotes.

More generally I'd describe your confusion as documentation error, the Autodesk documentation uses rather sloppy language.

- Generally, if the AutoLISP documentation on some general lisp function seems odd, it is useful to check other sources, see for example http://www.lispworks.com/documentation/HyperSpec/Body/f_not.htm, though occasionally you also then hit the differences between various lisp languages.

There should be no way you can get any difference between (not something) and (null something), they always produce the same result. (Actually, for example the Lispworks compiler produces exactly the same machine language code for either.)

- The usual style guide is to use NOT for logical negation and NULL for checking if a list is empty.

Neither NOT nor NULL have anything whatsoever to do with evaluation or bindings. They only take their argument and return T if it was nil and return nil for anything else.  Any evaluation happens only as a result of the Lisp interpreter/compiler evaluating everything (unless protected by quote)  in a function call, the same mechanism for any function whatsoever.

- as for bindings, consider (null (atom "")): it just inverts the value returned by the ATOM call, which is never bound to anything.

--