For example we can write a macro in Lisp and play around with it giving it code as data and see the result as code as data.

    CL-USER 1 > (defmacro while (condition &body body)
                  `(tagbody start
                            (if (not ,condition) (go end))
                            ,@body
                            (go start)
                            end))
    WHILE

    CL-USER 2 > (setf a 1)
    1

    CL-USER 3 > '(while (< a 4) (print a) (incf a))
    (WHILE (< A 4) (PRINT A) (INCF A))

    CL-USER 4 > (macroexpand-1 *)
    (TAGBODY START (IF (NOT (< A 4)) (GO END)) (PRINT A) (INCF A) (GO START) END)
    T

    CL-USER 5 > (pprint *)

    (TAGBODY
     START   (IF (NOT (< A 4)) (GO END))
             (PRINT A)
             (INCF A)
             (GO START)
     END)

    CL-USER 6 > (eval ***)

    1 
    2 
    3 
    NIL

Common Lisp source code (and the source code of its immediate ancestors) is not made of text strings. It's made of S-expressions, which are made of cons cells, symbols, numbers, and so on.

A text file of "Lisp source code" does not actually contain Lisp source code. It contains a text-based serialization of Lisp source code. Other serializations are possible (and there are things you can do in a Common Lisp repl to see some of them).

The "read" in "read-eval-print" means "deserialize the text into the source data that it's meant to represent".

This point is not trivial pedantry because the full power of the Lisp language is available to the read process, and can be brought to bear on how reading is done and what happens when you do it. Compilers for other languages certainly do read text strings and convert them into tree structures and so forth, but the difference is that those data structures are private to the compiler; the data structures that Lisp reads into are standard parts of Lisp's public API, as are the read function, the compile function, the eval function, the print function, and so on. It's all on the table for you to work with.

The same is true of the disposition of the s-expressions produced by the read process; you have an opportunity to bring the whole of the Lisp language to bear on those s-expressions before they are ever passed to (compile or) eval. Then, once again, what eval produces is S-expressions, and those, not strings, are passed to the print function. You once again have the opportunity to intervene in the process that produces the text serialization.

It so happens that I've spent the past six months working on an AI machine-control system written in Common Lisp, and every one of these capabilities was an important part of the work we were doing.