Re: Undefined in LISP

On 2025-03-21, Daniel Cerqueira <dan.list@lispclub.com> wrote:

In reading McCarthy's papers, there are things that struck me:
>
0. The only purpose of NIL is to mark the end of a list. When
representing falsity, McCarthy uses the symbol F .

This is not explain properly until the Lisp 1.5 Programmer's Manual
(1962), section 3.3 "Predicates and Truth in Lisp", where it gives the
"Humpty-Dumpty semantics" (suggesting that the author thought the system
being presented is hack, and viewing this aspect of it with some
derision).

It is there explained that the real Boolean values are the
symbol *T* (including the asterisks) and NIL.

The symbols T and F are variables.

The manual quite literally contradicts itself because in
an section 1.2 it still repeats the misleading information:

    In LISP, the values true and false are represented by the atomic
  symbols T and F, respec,tively.

But then:

  3.3 Predicates and Truth in LISP

    Although the rule for translating M-expressions into S-expressions
  states that T is (QUOTE T), it was stated that in the system one must
  always write T instead. Similarly, one must write F rather than (QUOTE
  F). The programmer may either accept this rule blindly or understand
  the following Humpty-Dumpty semantics.

  In the LISP programming system there are two atomic symbols that
  represent truth and falsity respectively. These two atomic symbols are
  *T* and NIL. It is these symbols rather than T and F that are the
  actual value of all predicates in the system. This is mainly a coding
  convenience.

  The atomic symbols T and F have APVAL's whose values are *T* and NIL,
  respectively.

More explanation follows; I invite you to find the document and look at
that.

1. There are some references to an expression being undefined.

I strongly suspect that all those undefined situations corresponded
to errors. Again in the Lisp 1.5 manual:

  6.3 Error Diagnostics

    When an error occurs in a LISP program, a diagnostic giving the
    nature of the error is printed out. The diagnostic gives the type of
    error, and the contents of certain registers at that time. In some
    cases a back-trace is also printed.  This is a list of functions
    that were entered recursively but not completed at the time of the
    error.  In most casee, the program continues with the next doublet.
    However, certain errors are fatal; in this case control is given to
    the monitor Overlord. Errors during Overlord also continue with
    Overlord.  A complete list of error diagnostics is given below, with
    comments.

The manual doesn't use the word undefined for many things.

One curious example of "undefined" is that if none of the conditions
in a COND are true, then the value of the expression is undefined.

CAR and CDR of a non-cons are also undefined.

No explicit documentation is given which states that these undefined
situations correspond to the errors of section 6.3 above.

However, the following text occurs which makes one such a connection.

One of the errors that are diagnosed listed in 6.3 is under the
category of Lap Errors:

  L  3  UNDEFINED SYMBOL

So LISP 1.5 had an error for undefined symbols. And earlier, the
section 1.4 (The LISP Meta-Language) has this text about free
variables:
                                                          n  n
  For example, in the function of two variables /\[[x;y];x ;y ] the
  variable n is not bound. This is called a free variable. It may be
  regarded a s a parameter. Unless n has been given a value before
  trying to compute with this function, the value of the
  function must be undefined.

OK, so in some abstract sense the value of the function is
undefined; but LISP also has an UNDEFINED SYMBOL LAP error.

What I don't know is whether this error would allow the computation to
continue and what would the actual value then be.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca