Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Kaz Kylheku <643-408-1753@kylheku.com> Newsgroups: comp.lang.lisp Subject: Re: Undefined in LISP Date: Sat, 22 Mar 2025 01:54:03 -0000 (UTC) Organization: A noiseless patient Spider Lines: 100 Message-ID: <20250321162624.702@kylheku.com> References: <87ldsyatmd.fsf@lispclub.com> Injection-Date: Sat, 22 Mar 2025 02:54:03 +0100 (CET) Injection-Info: dont-email.me; posting-host="c0cd031d8534b9b1dc01b8b7bed57c2a"; logging-data="2983267"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1821S3EZa5NRRA6I9+3pfPaUYzzPpMn3Mk=" User-Agent: slrn/pre1.0.4-9 (Linux) Cancel-Lock: sha1:RMdFvAwXw5cagC0Dyt4xfZ/XR/s= Bytes: 4972 On 2025-03-21, Daniel Cerqueira 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