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

Question

从理论角度看，Map与1元函数之间实际上没有区别

您对让函数实现Map接口有何看法？这将是有用的吗？如果已经考虑过并且大家决定不采用，那又是什么原因呢？我很愿意了解这种思考

Answer 1

将事物变成函数有很大的实用性，因为这是“你可以调用的东西”的主要抽象。将函数变成映射（数据）的实用性则小得多。你不能像数据一样轻松地读取/打印它们，通常你也不能将它们与其他数据组合等。此外，虽然所有映射都可以作为查找函数调用，但并非所有函数都可以作为映射调用，因此它只能应用于很窄的函数集。所以我说这不实用，我看不出从中能获得什么好处。

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说得非常在理。差点忘了那个ärke; 谢谢你们两位