Lisp compilers and interpreters are using s-expressions (-> nested lists of atoms) as source input. But these are not an AST. The compiler/interpreter has to fi

Lisp compilers and interpreters are using s-expressions (-> nested lists of atoms) as source input. But these are not an AST. The compiler/interpreter has to find out what these lists & atoms actually mean and may build an AST. Macros also see only lists/atoms. Macros then find out on their own what the embedded code should mean. That's different from some other languages, where macros work over an AST. Which means that the code is parsed and needs to follow a syntax. That's not the case in Common Lisp, macro forms can be in any syntax. (infix a + b) is legal syntax in Common Lisp, the macro could for example convert infix syntax to prefix. In a language where the operator + is defined to be a prefix operator (-> syntax), an expression prefix(+ a b) could not parse the thing into an addition call AST node, since it would need to know what syntax rules to use for the code. Somehow it would need to build an AST for a different syntax.