Emacs Lisp等Lisp方言宏展开的实际工作原理解析

你对Lisp宏的理解停留在“文本替换”层面，这是和C预处理器宏混淆导致的根本错误。Lisp宏（包括Emacs Lisp）从来不是做字符串/文本替换，而是运行在展开阶段的普通Lisp函数：它接收的参数是未求值的Lisp语法对象（语法树节点），执行后返回新的语法对象作为展开结果，宏体执行时完全遵循Lisp的常规求值规则，没有任何特殊的“参数替换”逻辑。

你的第一个版本宏报错的原因非常直接：
宏体里写的(checker 1)是标准的函数调用形式，Lisp求值函数调用时，会直接查找car位置（也就是函数位置）的符号checker对应的全局函数定义——你从来没有定义过名为checker的全局函数，自然会抛出void function错误。本质上这也是Emacs Lisp作为Lisp-2方言的特性：函数绑定和变量绑定分属两个独立的命名空间，函数位置的符号只会去函数命名空间查找，不会访问变量命名空间里的宏参数绑定，自然不会把它替换成你传入的check-one符号。

而funcall版本能正常运行，是因为checker出现在参数位置：宏体执行时，会按局部变量求值规则找到宏参数checker绑定的值——也就是你调用时传入的未求值符号check-one，funcall拿到这个符号后，会自动查找它对应的函数定义（也就是你之前defun定义的check-one），自然就能正常调用得到返回结果。

你之前预期的“先展开成带if的形式再继续求值”是完全错误的：宏体里的if是展开阶段就执行完毕的，根本不会出现在最终的展开结果里，最终返回给后续求值阶段的只有(print "yes")或者(print "no")二选一，不存在运行期判断的逻辑。

整个过程严格分为四个串行阶段，阶段之间完全隔离：

• 读取阶段：Reader把输入的文本代码解析成由cons cell、原子值组成的Lisp语法树，不会做任何求值操作。比如你输入的(check-foo check-one print)会被解析为一个列表：car是符号check-foo，两个元素分别是符号check-one、符号print。
• 宏识别阶段：解释器/编译器检测到当前列表的car是绑定为宏的符号，就会暂停对这个列表的求值，转而启动宏展开流程。
• 展开执行阶段：调用宏对应的展开函数，把解析得到的未求值参数（也就是刚才的两个符号对象）作为实参传入，在展开期的词法作用域里执行宏体代码，这个阶段的执行规则和普通Lisp函数完全一致：函数位置的符号查全局函数定义，变量位置的符号查当前作用域的变量绑定。宏体执行结束后必须返回一个合法的Lisp语法对象。
• 递归展开阶段：对宏返回的语法对象做重复检测，如果里面还有宏调用就继续展开，直到所有宏都被处理完毕，得到的最终纯Lisp代码才会进入求值/编译流程，在运行期执行。

• Common Lisp：核心逻辑和Emacs Lisp完全一致，属于非卫生的过程式宏，同样操作原生语法对象，函数位置的符号默认查找全局函数绑定，调用传入的函数参数必须显式用funcall；额外提供了编译器宏、读取宏、宏展开环境控制等更丰富的元编程能力。
• Scheme（R5RS/R7RS标准）：默认提供卫生的模式匹配宏（syntax-rules），通过模板匹配完成展开，自动避免变量捕获，不需要手动构造语法对象；部分实现（如Chez Scheme、Racket）也提供低级别过程式宏API，允许操作带作用域标记的语法对象，但依然遵循展开期/运行期分离的规则，不存在文本替换逻辑。
• Clojure：属于非卫生过程式宏，展开期逻辑和Emacs Lisp/Common Lisp类似，额外做了语法对象的上下文标记避免变量捕获，函数位置的符号默认解析为当前命名空间的全局函数，调用传入的函数值同样需要显式处理。

• Emacs Lisp官方手册：内置的Macros章节是Emacs Lisp宏机制最准确的一手说明，在Emacs中执行C-h i m Elisp m Macros即可直接查看。
• 《On Lisp》：Paul Graham撰写的Common Lisp经典著作，对宏的本质、展开期/运行期分离、宏的设计模式讲解极为透彻，核心逻辑完全适用于Emacs Lisp类过程式宏。
• 《Let Over Lambda》：Doug Hoyte所著的进阶宏编程书籍，深入讲解展开期计算、宏作为元编程工具的底层实现逻辑。
• 《计算机程序的构造和解释》（SICP）：虽然以Scheme为教学语言，但对解释器分层模型、元编程逻辑的讲解能帮你彻底打通读取-展开-求值全流程的底层认知。

内容的提问来源于stack exchange，提问作者Isabella