解析‘Is a macro, not a function’错误：宏与函数定义顺序差异缘由？

我曾多次遇到is a macro, not a function错误，但难以复现其成因。后来发现，错误源于在同一文件中使用宏的位置早于宏的定义。

示例如下：
在SBCL中，我编写了一个处理终端交互式中断的函数：

(defun some-long-running-thread ()
  
  ...

  #+sbcl
  (sb-sys:interactive-interrupt ()
    (progn
      (color :red (princ "C-c was pressed")) ;; <-- my macro
      (uiop:quit))))

(defmacro color (color &body body)
  `(multiple-value-bind (col val)
     (cl-ansi-text:with-color (,color)
       (progn
         ,@body))
     (declare (ignore col))
     val))

想请教：为何函数可以任意顺序定义，而宏却不行？背后的底层逻辑是什么？

注：我常在同一文件中定义并使用宏。

核心原因在于Lisp的编译/求值流程中，函数和宏的处理时机完全不同：

1. 函数的处理逻辑 #

函数调用是在运行时被解析的：

• 当你定义一个函数defun foo () (bar)时，编译器只会记录"foo这个函数里要调用bar"，并不会立即去查找bar的定义。
• 只有当程序实际运行到(bar)这一行时，Lisp才会去环境里查找bar的函数定义——哪怕bar是在foo之后定义的，只要运行时它已经存在，就能正常执行。
• 这也是Lisp支持递归函数的原因：你在定义foo时调用foo，只要运行时foo已经被定义完成，就可以正常执行。

2. 宏的处理逻辑 #

宏是在**编译期（或读取期，具体取决于Lisp实现）**被展开的：

• 宏本质是代码生成器，当编译器遇到(color :red ...)时，它需要立刻找到color宏的定义，把这段代码展开成普通的Lisp代码，才能继续编译后续内容。
• 如果此时color宏还没被定义，编译器不知道该怎么展开这段代码，就会把它当成普通函数调用处理——但实际上color是宏不是函数，于是就抛出is a macro, not a function的错误。

总结 #

• 函数采用"延迟查找"机制，直到运行时才去查找定义；
• 宏需要"即时展开"，编译时必须已经存在定义。

这就是为什么在宏定义前使用它会报错，而函数却可以随意调整定义顺序。

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