>> "Lisp is better because it is homoiconic"
>- Lisp is better because it manipulates the same data that the program code is represented in (car works on a data list, and it works on a code list as well).
Don't those two sentences mean the same?
>- Lisp is better because it manipulates the same data that the program code is represented in (car works on a data list, and it works on a code list as well).
Don't those two sentences mean the same?
Notably he doesn't do any interesting tree transformations on the code because tree structures in list are just a collection of twisty nameless tuples that all look alike. If you were trying to do nontrivial transformations on code you'd be better off with an AST in a language like Java or Typescript. In the end the dragon book is On Lisp squared or cubed, that is, games people play with macros are a pale shadow of what you can do if you actually understand how compilers work.
In Common Lisp, the homoiconic feature is the ed function which allows you to edit the source code of a function. Support for ed is implementation-defined!
It may be absent (e.g. in a Common Lisp that compiles everything to machine code). A Common Lisp that compiles all forms and doesn't support the ed function isn't homoiconic.