如何在查看Clojure代码时识别哪些表单是宏,哪些是函数？

Question

Lisp/Clojure代码在语法上具有一致性,这是一个加分点,因为不需要理解各种不同的结构.但有时通过使用不同的语法来查看一段代码更容易理解,因为这是一个切换案例,或者这是模式匹配构造等而没有实际读取文本.

几个月前我已经开始使用Clojure,我已经意识到我无法理解代码而不读取表单的名称,然后使用Google搜索它是宏还是函数以及它是如何工作的.

事实证明,无论语法的一致性如何,一段Clojure代码都是不统一的.

它可能看起来像一个函数,但如果它是一个宏,那么它可能不会评估它的所有参数.

是否存在所有宏使用的命名约定或缩进样式,因此某人更容易通过名称掌握正在发生的事情？

Answer 1

我认为最有用的直觉来自于理解给定运算符/Var 的目的。精心设计的宏根本无法编写为函数，但仍然可以使用相同的语法提供相同的功能，因为如果可以的话，它们实际上会编写为函数（请参阅上面的“精心设计”部分！）。¹因此，如果您正在处理一个不可能是常规函数的构造，那么您就知道它不是；否则很可能是这样。

此外，了解库导出的变量的常用方法可以告诉您您是在预先处理宏还是函数。doc(表示(doc foo)这foo是一个靠近其输出顶部的宏，如果情况确实如此)，source(因为它为您提供了整个代码)和M-.(使用 nrepl.el 或 swank-clojure 跳转到 Emacs 中的定义；M-,跳转后退）。文档可能会提及什么是宏，什么不是（除了文档字符串不一定如此，因为访问文档字符串的所有常用方法已经告诉您是否正在处理宏，如上所述）。

如果您浏览一段代码，目的是粗略地了解它可能执行的操作，假设各个运算符执行其名称所建议的功能，那么 (1) 名称具有足够的暗示性，您会得到了解代码的意图，因此您甚至不需要关心哪些运算符恰好是宏，或者（2）名称没有足够的暗示性，因此您需要深入研究文档或源代码无论如何，您首先要了解的是其中哪些运算符被注册为宏。

最后，尽管有特定于特定用例的某些约定，但宏没有单一的命名样式。例如，with-foo-style 构造往往是方便的宏，其目的是简化处理类型资源foo；dofoo-style 构造往往是需要执行表达式主体的宏（执行多少次以及设置哪些附加上下文取决于宏；该家族最基本的成员 ，do实际上是一种特殊形式而不是宏）；deffoo-style 构造引入了新的 Var 或类似类型的实体。

值得指出的是，类似的模式有时会被打破。例如，大多数线程构造 ( ->&Co.) 都是宏，但xml->fromclojure.data.zip.xml是一个函数。当人们考虑所提供的功能时，这是完全有道理的，这让我们回到了操作员的目的是最有用的直觉来源这一点。

¹此规则可能存在一些例外情况。人们期望这些都被记录下来。当然，有些项目根本没有记录（或几乎没有记录）；到这里，问题就完全消失了，因为无论如何，人们都必须追寻源头才能理解事物的意义。