I'm not a big fan of 'homoiconic' either. I'm more in the 'source code as data' camp. > The first objection concerns the external representation. In the above

I'm not a big fan of 'homoiconic' either. I'm more in the 'source code as data' camp. > The first objection concerns the external representation. In the above we simply stated that the external representation is an s-expression. In most practical programming environments, however, the actual representation of program sources is as text files which contain strings of characters. It is only after parsing this text that the representation is really an s-expression. In other words: in practical environments the external representation is not an s-expression, but text. The point is that Lisp s-expressions are an external representation of data and that Lisp programs are represented as s-expressions. Various programmatic interfaces see this source code as data: for example the function EVAL or the macro expander. > The second objection concerns the internal representation. Practical implementations of Lisp interpreters do generally not operate actually directly on s-expressions internally for performance reasons. Actually they do. The definition of 'Lisp interpreter' is that it operates on source code as data (lists, symbols, ...). Lisp has other ways to execute: as compiled byte code, as compiled native code, etc. -> but that's not a Lisp interpreter.