{QUOTE Mapping} Page 7
What the QUOTE notation achieves is a simple mapping of the entire set of S-expressions into a subset of itself; this mapping is trivially invertible. This is necessary in order to leave some S-expressions left over to represent other things.
This idea may be applied to natural numbers as well. We can "quote" a number by doubling it. In this way every even number represents half of itself, just as the S-expression (QUOTE α) represents the S-expression in its cadr. This leaves all the odd numbers for other purposes. For example, we can define an ordered set of variables and let 3N encode the N'th variable, for N>10. We can also let 31 mean COND; 32 mean LAMBDA, etc. We can then encode a procedure call as 5f7x11y13z ... where f is the encoding of the procedure and x, y, z, ... are the encodings of the arguments; COND forms and LAMBDA-expressions can be similarly encoded. For example,
(COND ((NULL A) 3) (T 6))
might be encoded as the number
5317(5(5314217310)76)11(5348712)
In this manner we can encode all of the LISP language as natural numbers. This is an example of the technique of "Gödelization".
{QUOTE Shafts the Compiler} Page 19
We emphasize that it is not the presence of dynamically scoped variables which makes standard LISP difficult for compilers, but the very fact that the LAMBDA-expressions are quoted. It is impossible in general to determine whether a quoted S-expression is intended to be code or just some constant data. Most LISP systems provide another kind of QUOTE called FUNCTION. In LISP 1 [LISP 1M] and LISP 1.5 [LISP 1.5M] this used to produce FUNARG objects (we call them &PROCEDURE objects), but in more recent LISP systems [Moon] [Teitelman] an ordinary FUNCTION-expression has been made equivalent to a quoted expression, serving only as a flag to the compiler that the quoted expression is intended as code. However, the introduction of the "'" notation for quoted expressions has led many programmers to prefer the use of QUOTE to FUNCTION for reasons of conciseness. This in turn has required changes to the compiler to specially recognize standard situations where this is used (e.g. the functional argument to MAPCAR), but this patch doesn't solve the problem generally.
