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

Question

从理论上讲，Map和1参数函数之间实际上并没有区别

您认为将函数实现为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) -- 这不是对称的（也没有任何理由要这样）。在关联类型中作为键/索引可以使用的有很多东西，而它们不能作为如果它们是函数那样在第一个位置使用。

---

完全有道理：）（我不是语言设计师，只是试着理解这个思维过程

Answer 3

从语义上看，Map 的某些属性无法转换为函数。Map 具有元素数量，允许列举它们包含的所有元素，这不可由函数完成。

另一个我可以看到的缺点是 get 的不可预测复杂性。当前，当你对一个 map 调用 get 时，你可以期望该操作是合理快速的。在 (get itentity 1000) 的情况下是这样，但在 (get #(do (Thread/sleep %) %) 1000) 的情况下则不是。我喜欢 Clojure 的可预测执行时间，如 conj，它保证了是 O(1)，而不会保证元素被插入到 coll 的末尾。

Comments

哇，第一个观点 @vlaaad 太有道理了。差点忘了这个：）谢谢你们俩