> but LISP code is not LISP data
well, that's obviously wrong. There are so many examples where LISP code is LISP data. It's also just one example, a code for a theorem prover can also be LISP data. The whole idea of LISP is to be able to write interpreters, code transformations, rule engines, compilers as LISP applications which process code in the form of lists.
The idea of being a LIST PROCESSOR is not an implementation detail, it is the core essence of LISP.
Re:Unix History and the `DC` Calculator
by kazinator on Monday September 02, 2024 @02:51PM
(#41427870)
> An arbitrary list is not a valid LISP expression
In Common Lisp terms, an arbitrary list is a valid expression, but not necessarily a valid form. A form is an expression that occurs in a context where it is presented for evaluation.
How John McCarthy and his coworkers explained LISP between 1958 and 1960 does not necessarily match what LISP really is.
What you say about the history of LISP is correct, but it is not relevant for your thesis, that LISP required parentheses because supposedly LISP code is data.
As you say, LISP is a list processing language. Its main data structure is the list. A list may have a variable number of elements, therefore its notation requires parentheses for enclosing the elements of the list.
On the other hand, a LISP program is data neither more nor less than a BASIC program is data or a C program is data.
After parsing, a LISP program may be stored in lists, but this is an implementation detail that does not matter for the definition of the language. If desired, any program written in any programming language can be stored in lists, after parsing.
An arbitrary list is not a valid LISP expression, i.e. valid LISP code, even if it is valid LISP data. Moreover, LISP code cannot be provided as an operand to a LISP function that processes lists. Only LISP data can be provided as an operand. LISP data includes quoted LISP code.
Quoted LISP code is LISP data and it is of course stored as a list, but unquoted LISP code, i.e. real LISP code, is not normally stored as a list, except in the simplest and least efficient LISP interpreters, which do not have any practical importance.
So LISP code is not LISP data and LISP data is not LISP code. They have different syntax and interchanging LISP code and LISP data in a LISP program will normally cause a syntax error, exactly like interchanging the content of a string constant with a statement (i.e. writing it without quotation marks) will cause a syntax error in most programming languages.
In any programming language you can have a string constant that stores some program sentences or expressions, which is data that can be parsed as code at run time. The only special feature of LISP is that its syntax is very simple and regular, so parsing and processing at run time is trivial.
As I have said, LISP data requires parentheses, but LISP code is not LISP data and it does not require parentheses for being data. It requires parentheses only because most standard functions and special forms may have a variable number of operands. One could make a LISP dialect where all functions with a variable number of operands, like ADD, would be restricted to a fixed number of operands and where the same restriction would be applied to the special forms, e.g. only IF would be used instead of COND, while AND and OR would have two operands. In such a LISP dialect there would be no need for parentheses in LISP code, but the LISP data, i.e. the lists would continue to need parentheses (but QUOTE would no longer be needed to differentiate lists from function/macro invocations).