所有 IObj 的位置数据

Question

只有列表包含位置数据，尽管大多数非原始数据类型实现了 IObj。这是为什么？在读取时会有人有兴趣为所有 IObj 对象添加位置数据吗？

user=> (meta '(1 2 3))
{:line 1, :column 8}
user=> (meta 'abc)
nil

Answer 1

您正在尝试解决什么问题？

Comments

我想要改进错误信息，以便直接指向受影响的对象，而不是指向周围列表。例如，在一个 `let` 块中，可以有一个深嵌套的符号未解析，语法错误将指向 `(let` 位置，而不是指向受影响的符号

    (let [{a :very-long-key
           b :another-long-key
           c :extremely-annoyingly-long-key
           {:键 [dddddddddddd eeeeeeeeeeee fffffffff]}
          :as 选项}
         :final-very-long-key} d]
      '...)

    ; 在 (example.clj:1:1) 编译时语法错误。
    ; 无法在当前上下文中解析符号：d

这也可以说是编译错误在 (example.clj:6:30)，因为那里有 `d`。

另一个例子是hiccup语法，这是一种流行的HTML编写方法，主要使用vector和关键词。一些库，例如Reagent，对以符号开始的vector处理不同。如果其中一个符号拼写错误，调用 `r/render` 的周围将高亮显示为失败，而不是特定的符号，这可能在以下几行（如我在工作的某些代码库中看到的那样）（:苦笑）。

我还认为在处理不配对的定界符时这可能很有用。目前，如果您说 `(some-fn ... [a b c)` 并且在开方括号和闭圆括号之间有行距，错误将指向闭圆括号。如果所有括号都携带位置数据，则错误可以表示为 "在 (example.clj:N:M) 读取源错误。不匹配的定界符：)。期望在 (example.clj:X:Y) 处匹配 []"

---

我忘记提到这对编写宏的人来说也是有用的，他们可以使用非列表的位置数据来编写有信息的错误消息。我不时看到人们对宏会丢弃位置数据表示遗憾，这将有助于改善这种情况。

---

我对这个特性也很感兴趣。我愿意与 `clojure.lang.Compiler/analyze` 一起使用它，以找到给定Clojure形式中所有本地绑定的用法，在一个Clojure编辑器中，突出显示所有这些用法，并允许用户重命名绑定及其所有用法。

就目前而言，我必须依赖于 clojure.tools.reader 将行号和列号分配给每个读取的形式。

除此之外，我认为这个特性将使其他有用的静态分析和错误报告特性成为可能。

就我的用途而言，至少，如果这是 `read` 的可选功能并且默认禁用，那就足够了。