Re: Undefined in LISP

On 3/21/2"025 4:47 PM, 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 .

NIL has always been a symbol that represented the empty list. A wee bit of experimental programing with early (middle or late) Lisps shows that it saves a lot of typing to 1) also have NIL be false and 2) let CAR and CDR applied to NIL be NIL. Point 1 was recognized and accepted by almost everyone early on. Point 2 was not adopted by some until around the early 1970s! In fact, CAR or CDR of NIL fired off a runtime error in dissenters' systems; this was the MAJOR source of error messages in those systems and it mostly caught mind farts, not cases where a value of NIL would have solved the problem.

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

I believe that undefined in that context has the same meaning you would find in the C spec or the Common Lisp spec: the behavior of the "undefined instance" is not defined and will be implementation dependent.

I would like to know your thoughts, about what being undefined actually
is. Should an undefined expression be represented by a symbol, or should
an undefined expression be silent (without returning a symbol)?

Virtually all modern Lisps use the IEEE floating point specs which define objects that represent plus and minus infinities of all available precision (single, double, etc.) and not-a-number; thus, it is possible to capture the results of an evaluation and validate that "it worked" or not. I've seen very very few cases of Lisp code that have used this capability - perhaps that is because very very few Lisp codes do extensive arithmetic or implement numeric analyses. There is also the fact that modern (and not so modern Lisps) provide extensive facilities to generate, catch, and handle typed errors. Those facilities provide much sharper methods to deal with evaluations that go awry.
--
Jeff Barnett