A simple question

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Some miscellaneous observations on this issue...

In my opinion, it is not appropriate to document that NOT and NULL are the
same even if they have identical behavior. If their intended uses differ
(as I would claim they do), they are not interchangeable. Perhaps we can
get this wording fixed in the upcoming manual. People should use NULL for
lists and not for predicates as a matter of style. Although (NULL (NULL x))
is not "an error" in the CLtL sense, I'd put red marks next to it if I were
teaching a programming course and someone turned in a program that did it.

By the way, there are GC implications to returning the thing itself and not
T. If the x was a large structure that was not otherwise pointed to, it
would be a shame for it to not get GC'd just because someone was passing
it around for truth value.

Also, there are data abstraction issues. You run the risk of accidentally
violating the integrity of private data structures if you give them away,
and the compilers should be leary of optimizations that can do this kind
of thing.

In T (Yale Scheme), we actually created a whole line of operators called
MEMBER?, ASSOC?, etc. which were like MEMBER, ASSOC, etc. but returned
T/NIL for cases where abstraction and/or GC behavior was an issue.

On the LispM, this optimization would be particularly funny for stack lists
since I guess you could claim that a stack list could `rightly' be returned
here (it being non-null, after all, regardless of what its ever-varying
contents were). If you never used it for anything other than its existence
and non-nullness...

This optimization, by the way, is related to the (+ X 0) => X optimization,
which can be pretty bizarre error-checking-wise when X is a string or some
other non-addable quantity and SAFETY is high (because no error may get
signalled where the intuition may be that one should be). Presumably the
next CL standard should take some stand on optimizations like this so that
users can know what to expect (or know to expect nothing) and implementors
can know what to feel comfortable about providing.