爲什麼FEXPR在Common Lisp中被放棄？

許多LISPs都有FEXPRs，但它們不包含在CL中。
我讀到這是因爲FEXRP在靜態分析中效果不好。
有人可以解釋這一點嗎？爲什麼FEXPR在Common Lisp中被放棄？

2013-08-19 lonjil

就我個人而言，如果您在Stackoverflow上發佈有關真正編程問題的問題，我更喜歡。另外你的問題是錯的：'統計分析' - 那是什麼？ Common Lisp也沒有「放棄」FEXPR。在CL出現之前，它們已經過時了。 –

在對Lisp和函數式編程的1980年會議，肯特·皮特曼提交的論文「在Lisp的特殊形式的」中，他討論了宏和fexprs的優點和缺點，並最終致命fexprs 。他的中心反對意見是，在允許fexprs的Lisp方言中，靜態分析不能確定運算符是代表普通函數還是fexpr - 因此，靜態分析不能確定操作數是否將被評估。尤其是，編譯器無法確定是否可以安全地優化子表達式，因爲子表達式可能在運行時將其視爲未評估的數據。

來源

2013-08-19 23:48:12

是的，我已閱讀過，但並未真正解釋所有原因。還是最後一件事是唯一的原因？ – lonjil

除了我在這裏閱讀的文章，我不知道任何關於fexprs的內容，@龍吉，但這對我來說似乎是一個足夠的理由。據我瞭解，Pitman說，包括fexprs將會減慢運行時使用lambdas的代碼的速度，因爲編譯器將無法優化代碼。 – Mars

肯特皮特曼called放棄fexpr，因爲它似乎是不可能編譯它。

有關fexpr的深入討論，請參閱John N. Shutt的博士論文 Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction。

來源

2013-08-20 00:43:28 piokuc

FEXPR更像DEFUN而不是DEFMACRO，因爲它們成爲頭等對象。這對於編譯器來說似乎很困難，因爲在編譯時它不知道某個函數或宏是否是某個函數或宏，因此在編譯時可能會有一些宏未擴展。你可以read the paper here with comments。

在閱讀之後，我不確定他的結論是否仍然屬實，因爲我們的編譯器在進行高級常量摺疊和其他優化時更好。無論如何，更高階的宏不像高階函數那樣有用，所以我們不會錯過它們。

Paul Grahams Arc has anonymous macros and kernel has them too所以它並沒有完全消失，但我覺得這只是爲了方便。試試map，你會發現它不是很有用。

來源

2013-08-20 01:00:44 Sylwester

fexprs不是匿名宏。你的解釋在很多方面都是錯誤的。 –

解釋它們的更好方法是它們是運行時宏。 – Zaz

是的，但你會盡量擴大他們，你可以。問題是你不擴展函數，如果你可以傳遞一個fexpr作爲參數，你需要在運行時擴展它們。 – Sylwester

爲什麼FEXPR在Common Lisp中被放棄？

回答

相關問題