[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The T and NIL issues (and etc.)

The msg of following dateline certainly describes well the status
quo in MacLISP (both PDP10 and LISPM), as well pointing out the
T is special-cased in CASE clauses.
    Date: Sunday, 14 March 1982  14:40-EST
    From: Symbolics Technical Staff
    Reply-to: Moon@SCRC-TENEX@MIT-MC
    To:   Common-Lisp at SU-AI
    Subject: The T and NIL issues
    . . .
But as EAK says, there  is no reasoning given, beyond the authors'
personal preference, for retaining the "wart" of NIL = ().

One comment from that msg deserves special attention:
    T and NIL are just like the hundreds of other reserved words in Lisp,
    dozens of which are reserved as variables, most of the rest as functions.
    . . .
Why should even dozens of user-visible variables be reserved?  This is one
of the strongest complaints against LISP heard around some MIT quarters --
that it has become too hairy, and the presence of the LISPManual doesn't
help any.  And again, even if there be many "reserved" names for functions,
the separabililty of function-cell/value-cell makes this irrelevant to the
T/NIL issue.

Perhaps the package system could "hide" more of the systemic
function/variables, but why should it come up now?  The notion of
lexically-scoped variables, as mentioned in my note
    Date: 5 March 1982 12:09-EST
    From: Jon L White <JONL at MIT-MC>
    Subject: How useful will a liberated T and NIL be?
    To: Hedrick at RUTGERS
indicates that the variable T (and indeed NIL too) can be fully useful,
even if its global value serves in its present "status quo" capacity.
E.g., in
	  (T PRED)
	  (#T () )))
the local declaration will totally isolate "T" from the effects of any
global binding.