> Not exactly. That is exactly the point. Lisp syntax works differently. s-expressions are a data language and the Lisp syntax is not defined over characters,

> Not exactly. That is exactly the point. Lisp syntax works differently. s-expressions are a data language and the Lisp syntax is not defined over characters, but over s-expressions. > i.e. something that looks like lisp. No, it would just look like s-expressions. You could define a completely different syntax and semantics on top of s-expressions: Logic (like Prolog), Postfix, ... No one says that s-expression need to have the operator first. That's what Lisp defines as syntax. But you could write a postfix in s-expressions_ ((3 4 +) 9 (pi sin) pi) 2 *) Above is a valid s-expression, but it is not valid Lisp. As such it does not look like Lisp, but it looks like a postfix language encoded on top of s-expressions. If a reader would reverse all expressions, then it could be executed as Lisp. You could also define a syntax where parentheses are replaced by significant indentation. s-expressions are not Lisp syntax, they are a data syntax which is used to encode Lisp. Historically s-expression were also defined only for data and Lisp code used m-expressions for programs and s-expressions for data. CADR would be written similar to: cadr[A]=car[cdr[A]] The function would then be called on data: cadr[(1,2)] -> 2 That's would Lisp code might look like, if it were not found out that one could als represent the code as s-expressions and that this would have interesting effects. Lisp designers tried to get away from this syntax several times. ML switched [] and (): similar to: fun cadr (l) = car ( cdr (l)) called then similar to cadr([1,2]) (read) reads every s-expression. Not just Lisp code. It knows nothing about the syntax of the Lisp constructs: DEFUN, LET, DEFCLASS, UNWIND-PROTECT, DOTIMES, ... When then EVAL gets called the s-expression external syntax is gone. EVAL gets Lisp code as Lisp data, not as characters or strings.