为什么在Common Lisp中放弃了FEXPR？

许多LISP都有FEXPR，但它们不包括在CL中。
我读到这是因为FEXRPs不能很好地用于静态分析。
有人能解释一下吗？

来自：

在1980年的Lisp和函数式编程会议上，Kent Pitman 提交了一篇论文“Lisp中的特殊形式”，其中他讨论了 宏和FEXPR的优缺点，以及最终 谴责FEXPR。他的主要反对意见是，用口齿不清的方言来说 这样一来，静态分析通常无法确定 运算符表示普通函数或fexpr-因此， 静态分析无法确定操作数是否将被删除 评价的。特别是，编译器无法判断 可以安全地优化子表达式，因为子表达式可能 在运行时被视为未评估的数据

肯特·皮特曼（Kent Pitman）因为不可能编译而放弃了fexpr

有关fexpr的深入讨论，请参阅John N.Shutt的博士论文

---

.

FEXPR

更像是

DEFUN

而不是

DEFMACRO

，因为它们成为了第一类对象。这对于编译器来说似乎很困难，因为它无法在编译时知道某个东西是函数还是宏，而可能会留下一些宏在编译时没有展开。你可以

在阅读之后，我不确定他的结论是否仍然正确，因为我们的编译器更擅长高级常量折叠和其他优化。无论如何，高阶宏没有高阶函数那么有用，所以我们不会太想念它们

---

保罗·格雷厄姆斯，所以它并没有完全消失，但我觉得那只是为了方便。用它试试

map

，你会发现它没有多大用处。

是的，我读过，但它并没有真正解释它的所有原因。或者最后一件事是唯一的原因？除了我在这里读到的以外，我对FEXPR一无所知，@lonji，但这对我来说似乎是一个足够好的理由。据我所知，Pitman说，包含FEXPR会降低运行时使用lambda的代码的速度，因为编译器无法优化该代码。FEXPR不是匿名宏。你的解释在几个方面都是错误的。更好的解释方法是它们是运行时宏。是的，但你可以尝试在你能扩展的地方扩展它们。问题是你不展开函数，如果你可以传递一个fexpr作为参数，你有时需要在运行时展开它们。就个人而言，我更喜欢你在Stackoverflow上发布关于真实编程问题的问题。另外，你的问题是错误的：“统计分析”——那是什么？同样，Common Lisp并没有“放弃”FEXPR。在CL存在之前，它们已经过时了。