实现Map接口的Clojure函数。为什么或为什么不这样做？

Question

从理论的角度来看，Map与一元函数之间并没有真正的区别

您如何看待函数实现Map接口？这将是有用的吗？如果考虑了这一点，但您认为不采取它，那为什么呢？我渴望了解这种思考过程

Answer 1

将事物转换为函数有很大的实用性，因为这是“你要调用的东西”的主要抽象。将函数转换为数据（Map）的实用性就小多了。你不能像数据一样轻松地阅读/打印它们，你不能通常地将它们与其他数据进行组合等。此外，虽然所有Map都可以作为查找函数调用，但并非所有函数都可以作为Map调用，因此它只能适用于一小部分函数。所以，我认为这不实用，我不认为从中可以得到任何好处。

Answer 2

你试图解决什么问题？

Comments

并不是试图解决这个问题
我只是想了解一下符号和关键字如何作为函数来对其传递的第二个参数进行查找（一个映射）

所以我就想知道一个函数是否也是某种映射，所以应该是(:key some-fn)应该能工作，但是没关系，因为我们总是可以写成(some-fn :key)

我认为关键字/符号作为函数只是方便而已？

---

但我肯定会考虑它是否以任何方式有帮助

---

另外，注意到你可以这样说(some-map "a-key")，但你说不出("a-key" some-map)，你也可以这样说(some-vector 42)，但你说不出(42 some-vector) -- 它不是对称的（也没有理由要对称）。在关联类型中，可以作为key/index的有很多事情，不能作为就像函数一样在第一个位置使用。

---

完全有道理 :) 我不是语言设计者，只是试着理解这个思考过程

Answer 3

从语义上看，Map的一些特性是无法映射到函数的。Map有元素数量，允许遍历其包含的所有元素，这是函数无法做到的。

我认为的另一个缺点是get的不可预测复杂性。当前在map上调用get时，您可以预期操作相对较快。在(get itentity 1000)的情况下是如此，但是在(get #(do (Thread/sleep %) %) 1000)的情况下则不是。我喜欢Clojure的可预测执行时间，例如conj，它保证了操作时间复杂度为O(1)，但并不保证元素会被插入到集合的末尾。

Comments

哇，vlaaad的第一个观点非常有道理。我差点就忘了这一点 :) 谢谢你们两位