Though the philosophy is different, I'm not sure I see an advantage for NIL when you just look at the effect it has on a programmer's code. You can still have a "NULL-pointer dereference" in CL, except the error is rephrased as "SYSTEM::%STRUCTURE-REF: NIL is not a structure of type X" or whatever. And you still have to have "(if (not (null x)) ...)" which doesn't do much for you, regardless of the underlying theory.
(defmethod quack ((foo string))
... ;; foo is never anything but a string here.
... ;; definitely not nil!
)
(defmethod quack ((foo null))
... ;; foo is definitely nil here
)
Unlike in languages where you have a String reference that can be null, a CLOS method parameter specialized to a string cannot be NIL!
We can also have this piece of minimalism, quite often recurring in Lisp code:
;; yield x if it is not nil, else yield y
(or x y)
Or play hardball:
;; if calculation signals an error,
;; catch it and keep going
(ignore-errors (calculation x))
After programming in Lisp for a while you would never write:
(if (not (null x)) ...)
because it is verbose way of expressing:
(if x ...)
Every value is its own test for non-nullness, since every value is a generalized boolean which stands for falsehood if it is nil, and truth otherwise.
