错误信息中令人困惑的函数名称后缀

Question

一些核心函数名称在使用中带有奇怪的编码后缀。

例如，当向{{inc}}、{{assoc}}和{{dissoc}}传递错误数量参数时，每个错误信息报告的函数名称都不同


clj -Srepro -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta4"}}}'



user=> (inc)
编译inc时出现语法错误。
给clojure.core/inc--inliner--5436传递了错误的参数数量（0）。
user=> (assoc)
评估错误（ArityException）在clojure.lang.AFn.throwArity (AFn.java:429)中抛出。
给clojure.core/assoc--5316传递了错误的参数数量（0）。
user=> (dissoc)
评估错误（ArityException）在clojure.lang.AFn.throwArity (AFn.java:429)中抛出。
给clojure.core/dissoc传递了错误的参数数量（0）。


从用户的角度来看，这种行为是没有动机且令人困惑的。也许这样的名称应该进一步解码并打印时不加后缀。

Answer 1

评论者：alexmiller

这里的第一个是一个内联函数，发生在编译期间，所以与其他不同。因为它被内联，所以不能特定化。那里的名称部分是在编译过程中生成的。这个根据名称构建的规律性，可能会被修复，尽管我不认为这是一个特别高的优先级。

应用CLJ-2420后，后两个将会有所不同

user=> (assoc) 执行错误（ArityException）在user$eval154/invokeStatic (REPL:1)中。向clojure.core/assoc--5406传递了错误的参数数量（0）。

这里的变化实际上省略了所有内部帧，现在报告最顶层的用户帧（在这里，它发生在REPL调用中，但如果它在一个用户命名空间中，你会看到那个）。

我认为在这两种情况下，你看到的数据是 Clojure 中常用的标准技术，所以问题可能在于是否可能以系统化的方式解决这个问题。目前函数没有内在地携带它们的原始名称，因此从类名称中解包永远不会是一个万无一失的机制。

值得考虑如何做得更好，但这不是我希望近期关注的。

Answer 2

参考： https://clojure.atlassian.net/browse/CLJ-2422 （由 glts 报告）