为什么在一般情况下，eval不应该支持字符串和数字等其他简单类型的键访问语义？（也许还有布尔值，等等）？

Question

有关 clojureverse 上的一个线程： https://clojureverse.org/t/x-x-auto-transducifying-thread-macros/8122/26

，其中作者的库提供了一种 ->> 的归约版本，名为 x>>，它识别归约器，并尝试将线程表达式转换成高效的归约形式。

作者随后决定将字符串和数字的键访问语义合并进去，以便在表达式中使用更简洁的 get 或 get-in。类似于下面这样：

(let [m {1 {"b" [0 1 {:c :res}]}}]
     (x> m 1 "b" 2 :c name)) ;=> "res"

这与键描述性习惯用法类似。

(-> m :a :b :c) ;;some-nested-value

在一般情况下，为什么 eval 不应该支持字符串和数字等其他简单类型的键访问语义呢？
除了无法扩展 IFn 到字符串和数字（这将需要使用附加的类型检查进行dispatch，而不是专注于 IFn）之外，是否有任何语言设计上的反对论证？我一时无法想到任何理由。

Answer 1

"除了无法扩展 IFn 到字符串和数字”是相当关键的。我们无法拥有这些类型，并且在这些检查中添加这些检查将需要在所有函数评估的路径中，所以我认为这是一个非启动项。