Lambda the Ultimate

You can do this in any Turing-complete language. I would say that a defining quality of LISP is that the quoting syntax lets you write data which look like what they represent, if they are intended to represent LISP code.

[From the article:] What we have here is a remarkably elegant model of computation. Using just quote, atom, eq, car, cdr, cons and cond, we can define a function, eval., that actually implements our language, and then using that we can define any additional function we want.

You don't need any of that. In particular, quoting is superfluous. You can define everything using variables, lambda and application. Now that's elegant!

(Actually, you don't even need variables or lambda. Every computable function can be expressed using application and a single constant. See The systematic construction of a one-combinator basis by Jeroen Fokker. But using a one-combinator basis for computable functions is like reducing classical logic to NAND... interesting, but not practical.)

Maybe these claim can be substantiated from a historical point of view. I am not sure, but I think Lisp was designed as an attempt to find a notation useful for describing its own evaluator.

Obviously, from a theoretical point of view the results of Turing, Church etc. predate Lisp.

Another way to look at it is how much code is required for a language to implement itself. Since the features mentioned above are part of the definition of Lisp, a very small Lisp implementation that provides these basic features is capable of implementing itself. Even if you tried to implement a version of the untyped lambda calculus in itself - which might be smaller - by the time you implement a reader and some of the other necessary capabilities, it would look a lot like Lisp. In terms of the amount of code required for a self-implementation, Lisp would likely be quite far ahead of most other languages, with the possible exception of languages like Forth and Postscript.

If I'm wrong, I'm most interested to know about other languages that would give Lisp serious competition in this area. Perhaps this would be a good candidate for a "shootout"!

Many of the benefits which Lisp provides in this area are upfront benefits. As the language being implemented becomes larger and more complex, Lisp doesn't necessarily provide more language-implementing utility than, say, the typed functional languages. Those are also excellent for implementing languages, but most of them lack at least some of the features that makes this so easy in Lisp, so the initial steps may require a bit more work.

"The implementation of LISP" provides McCarthy's own perspective on the issue. A relevant quote:

"Another way to show that LISP was neater than Turing machines was to write a universal LISP function and show that it is briefer and more comprehensible than the description of a universal Turing machine. This was the LISP function eval[e,a], which computes the value of a LISP expression e - the second argument a being a list of assignments of values to variables. (a is needed to make the recursion work). Writing eval required inventing a notation representing LISP functions as LISP data, and such a notation was devised for the purposes of the paper with no thought that it would be used to express LISP programs in practice. Logical completeness required that the notation used to express functions used as functional arguments be extended to provide for recursive functions, and the LABEL notation was invented by Nathaniel Rochester for that purpose. D.M.R. Park pointed out that LABEL was logically unnecessary since the result could be achieved using only LAMBDA - by a construction analogous to Church's Y-operator, albeit in a more complicated way.

S.R. Russell noticed that eval could serve as an interpreter for LISP, promptly hand coded it, and we now had a programming language with an interpreter.

Here's another site with some interesting historical info, including copies of the early versions of McCarthy's "universal LISP function". The first two links on the above page are most relevant, with the second link being most detailed in terms of describing where McCarthy was coming from during the development of LISP.

Finally, The Survival of LISP provides a list of ideas which McCarthy considers to characterize LISP. Almost all of these are important to allowing LISP to easily be implemented in itself. In particular, #12 is "The LISP function eval that serves both as a formal definition of the language and as an interpreter".