TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: AWW on October 28, 2011, 12:55:24 PM
-
I know that Nil is the return value for an expression that is evaluated as false in the if/or/while functions. But what about coding similar to this:
(Function
nil
Thanks for any input/clarification.
-
nil can also be an empty list:
nil == ()
-
Nil always evaluates to an empty list in LISP
(null nil) -> T
(listp nil) -> T
(equal nil '()) ->T
Not like some languages where nil is NOT T
-David
-
More, nil is the only LISP data which is both considered as a list and as an atom:
(listp nil) => T
(atom nil) => T
-
More, nil is the only LISP data which is both considered as a list and as an atom:
(listp nil) => T
(atom nil) => T
Amazing that the help files still do not list this:
atom
Verifies that an item is an atom
(atom item)
Arguments
item
Any AutoLISP element.
Some versions of LISP differ in their interpretation of atom, so be careful when converting from non-AutoLISP code.
Return Values
Nil if item is a list; otherwise T. Anything that is not a list is considered an atom.
Examples
Command: (setq a '(x y z))
(X Y Z)
Command: (setq b 'a)
A
Command: (atom 'a)
T
Command: (atom a)
nil
Command: (atom 'b)
T
Command: (atom b)
T
Command: (atom '(a b c))
nil
-David
-
So in this case, nil is a list or atom that returns T. Always thought nil was false and T was true.
-
T is true.
nil is both false and an empty list.
But you have to consider that LISP functions using predicates do not required the predicate to retun T (or nil), but a non nil value (or nil).
-
nil (http://exchange.autodesk.com/autocad/enu/online-help/browse#WS73099cc142f4875516d84be10ebc87a53f-7c59.htm)
Do you consider nil equivalent to a empty list?
Or does a empty list just point to nothing(How can you have a empty list? By definition can it really be considered a list before items are added to it?)
I guess those questions can depend on how you look it.
Kinda like null for some languages.
Look at it is as the bits that represent 0 or
that it points to nothing.
-
Yes,
nil can be seen as null (nothing) in some languages: a variable wich hasn't been assigned is nil, set a variable to nil is the same as set a variable to null in some languages.
How can you have a empty list? By definition can it really be considered a list before items are added to it?
Yes,
you have to consider nil as an empty list too :
(cons 1 nil) returns (1)
as [] in F#:
1 :: [] returns [1]
And it is used as false in predicate too.
-
I knew AutoLisp would have to have a representaion for for a empty list and was asking more in a abstract sense,
but isn't Lisp just a bunch of linked list and nil represents the tail?
-
but isn't Lisp just a bunch of linked list and nil represents the tail?
Yes, nil represents the tail of the last cons cell in a linked list.
(cons 1 (cons 2 (cons 3 (cons 4 nil)))) returns (1 2 3 4)
(http://img197.imageshack.us/img197/3082/conscell4.png)
'(1 2 3 4) is a shortcut for: '(1 . (2 . (3 . (4 . nil))))
A French thread (http://cadxp.com/index.php?/topic/29314-ces-listes-qui-nen-sont-pas/page__view__findpost__p__159425) about cons cells and linked lists
-
I guess someone deleted a post but had this quoted
An AutoLISP variable that has not been assigned a value is said to be nil. This is different from blank, which is considered a character string, and different from 0, which is a number. So, in addition to checking a variable for its current value, you can test to determine if the variable has been assigned a value.
Each variable consumes a small amount of memory, so it is good programming practice to reuse variable names or set variables to nil when their values are no longer needed. Setting a variable to nil releases the memory used to store that variable's value. If you no longer need the val variable, you can release its value from memory with the following expression
_$ (setq val nil)
I guess the difference is or I does setting a variable to a empty list also release the value?
-
T is true.
unless some bozo does this:
Command: (setq T nil)
nil
but:
Command: (eval t)
nil
Command: (atom t)
T
so,
Command: (setq t (atom t))
T
restores T to T
but if:
Command: (listp T)
T
we know that:
Command: (eval T)
nil
because nil is (as Gile pointed out) the only symbol which is both an atom & a list.
I know Gile knows all this - more for OP & other novices.:)
-
And Nil smaller all number ^^:
Command: (< nil -10000000)
T
Command: (< nil -10000000000000000000000000000)
T
-
I guess someone deleted a post but had this quoted
An AutoLISP variable that has not been assigned a value is said to be nil. This is different from blank, which is considered a character string, and different from 0, which is a number. So, in addition to checking a variable for its current value, you can test to determine if the variable has been assigned a value.
Each variable consumes a small amount of memory, so it is good programming practice to reuse variable names or set variables to nil when their values are no longer needed. Setting a variable to nil releases the memory used to store that variable's value. If you no longer need the val variable, you can release its value from memory with the following expression
_$ (setq val nil)
I guess the difference is or I does setting a variable to a empty list also release the value?
OK, I think I understand what you mean, and that makes sense.
Mainly, nil is nothing (null) because it's used to release memory, and it serves as well for some types explicitly defined in more strongly typed language (i.e. F#):
- the boolean false value
- an empty list (as [] in F#)
- the absence of a specific value as argument or function return (as () the F# unit type (http://msdn.microsoft.com/fr-fr/library/dd483472.aspx))
Here're some examples comparinf AutoLISP and F# (which is the strongly typed language closest to lISP I know).
nil as null (null isn't often used with F# which avoid the use mutable variables as it's more an imperative behavior)
_$ (setq s "foo")
"foo"
_$ (setq s nil)
nil
> let mutable s = "foo" ;;
val mutable s : string = "foo"
> s <- null ;;
val it : unit = ()
nil as false
_$ (= 0 1)
nil
> 0 = 1 ;;
val it : bool = false
nil as empty list
_$ (setq l nil)
nil
_$ (cons 1 l)
(1)
> let l = [] ;;
val l : 'a list
> 1 :: l ;;
val it : int list = [1]
nil as absence of a specific value
_$ (defun foo nil (alert "Hello"))
FOO
_$ (foo)
nil
> let foo () = printfn "Hello" ;;
val foo : unit -> unit
> foo () ;;
Hello
val it : unit = ()
-
I always thought they bound nil to an empty list is so that it would not error out on certain calls
You would think that this would produce an error:
(setq ed nil)
(cdr (assoc 10 ed))
But it doesn't because (assoc) is searching a list. There are several other examples of this behavior. -David
-
I always thought they bound nil to an empty list is so that it would not error out on certain calls
As LISP in a dynamic typed language, nil type checking is performed at run-time and I think it is bound according to the context.
-
Some good explanations and examples gile. :-)
-
Thanks gile!!
-
I wanted to re-visit this NIL thread again while analyzing this code here:
(DleaderWhile
;DleaderWhile subfunction call
nil
;empty list
(vlax-ename->vla-object (car DQobject))
;(retrieve first element of DQobject *list*) (transform DQobject entity to vla-object)
nil
;empty list
)
Notice I've added some comments for what I think is going on. So is this just setting the list empty? To be filled later within the program? Or to preserve memory?
-
Perhaps those arguments are boolean flags requiring a T/nil value, it would depend how those arguments are used in the function.