在Clojure的设计或实现初期，是否考虑过自动柯里化？

Question

今天我有了一个问题：自动柯里化在Clojure的设计或实现过程中是否被考虑过？

假设你有

(defn add [x y] (+ x y))

(map (add 2) [1 2 3 4 5])

如果Clojure支持自动柯里化，那么结果会是 [3 4 5 6 7]，但目前由于参数数量不匹配导致错误。我觉得这种行为比错误更具有生产力。所以我很好奇，如果曾经考虑过这样的特性，为什么有意识地避免它。

Answer 1

我对这个问题的完整答案不清楚，但下面是一个链接，指向了2008年10月在Clojure Google群组中的一次讨论，Rich Hickey对一个如何在Clojure中添加柯里化功能的建议进行了回应。

https://groups.google.com/forum/#!searchin/clojure/currying$20hickey|sort:date/clojure/Nsd-7Iagkws/0sVdoJl7bFgJ

Rich对currying肯定很了解。至于它被如何看待，我就不太清楚。匿名函数和Clojure的#()语法可以做的事情，currying做不到，尽管可能需要多打几个字。如果我的信息中没有提到，在链接的讨论线程中也没有提出，那么许多其他的设计权衡可能也未被提及，我觉得这并不奇怪。

Answer 2

https://stackoverflow.com/questions/31373507/rich-hickeys-reason-for-not-auto-currying-clojure-functions

TL;DR：Clojure被设计成具有可变参数的函数，这与currying是相排斥的。

如果你有currying，就无法使用命名（关键字）参数。

Comments

我想起了Clojure中的关键字参数。

Answer 3

另一个关于currying的旧讨论线程，涉及到Rich Hickey，还有一个名为appl的函数，它可以进行部分应用（我想这个名字“appl”在某种意义上也是对“application”这个词的戏谑的吧，因为它只是“application”的一小部分）：[链接](https://groups.google.com/forum/#!searchin/clojure/currying$20hickey%7Csort:date/clojure/TjvA5AQArUs/9bN78s4w-VkJ)

在现在的Clojure核心中，没有名为appl的函数。我不知道它的历史，直到在通过旧谷歌群组消息进行关键词搜索时才意识到它的存在。

Comments

这篇帖子还讨论了为什么+不能像可变参数那样进行柯里化

(+) ;=> 0
(+ n) ;=> n -- 并不意味着“加n”
(+ 1 2 3 4) ;=> 10

---

我觉得这有点道理！因为支持可变参数和关键字参数，所以不可能有自动柯里化。

但是，你可以写一个接受参数个数和函数的自适应柯里化函数。或者，还提出了各种宏。虽然，引入这种行为可能会让人迷糊。谢谢你的见解！

Answer 4

如果你不介意使用外部库，Clojure中可以实现柯里化

https://dragan.rocks/articles/18/Fluokitten-080-Fast-function-currying-in-Clojure