T and NIL.

[George J. Carrette <GJC at MIT-MC>]

#+FLAME-MODE '|
Existing bodies of working code are absolutely no consideration for
the NIL implementors in this particular issue. I guess this might be
obvious, but why should we be so callously radical? It is simply
that we have reason to beleive that existing code which depends
on the present relationship between list and symbol semantics
and predicate semantics which will not run as-is in NIL are
execedingly easy to find and fix. We also beleive that the
existing lisp 1.5 semantics are inadvertently overloaded,
implying that GET, PUTPROP, SYMEVAL, and other symbol primitives
may be used on the return value of predicates and the empty list, and
needlessly implying that evaluation-semantics need not reflect
datatype-semantics. |


In bringing up Macsyma and other originally pdp10-maclisp code in NIL,
I have found it much easier to deal with the predicate-issue than with
the fact that CAR and CDR do error-checking. Well, the CAR/CDR problem
had already been "smoked" out of Macsyma by the Lispmachine. There
was no need to do any QUERY-REPLACE, and no subtle bugs.
(Non-trivial amounts of LISPMACHINE code were also snarfed for use in NIL,
 although Copyright issues [NIL wants to be publick domain] may force
 a rewrite of these parts. The only Lispmachine code which depended on
 () being a symbol explicitly said so in a comment, since probably the
 author felt "funny" about it in the first place.)

There was only one line of Macsyma which legally depended on the return values
of predicates other than their TRUTHITY or FALSITY. There were a few more
lines of Macsyma which depended illegally on the return value of
predicates. These were situations where GET, PUTPROP, and REMPROP
were being used on the return value of predicate-like functions,
e.g. using REMPROP on the return value of the "CDR-ASSQ" idiom, using
GET on the return value of GET. In good-old "bare" pdp-10 maclisp
with only one program running in it, this is not a problem, but
=> On the lispmachine, which has a large environment, many usages of
   property lists, it can be very dangerous for programs to unwitingly
   share the property lists of global symbols T and NIL. <=

The other part of the picture is that we know we can write code
which doesn't have things like #T in it, and which will run in
COMMON-LISP regardless of what COMMON-LISP does.

-gjc