所有 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
           {:keys [dddddddddddd eeeeeeeeeeee fffffffff]
           :as options}
          :final-very-long-key} d]
      '...)

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

这可以改为说“语法错误编译在 (example.clj:6:30)”因为`d`就在那里。

另一个例子是hiccup语法，这是使用向量关键字编写HTML的一种流行方法。某些库，如Reagent，对以符号开头的向量有不同的处理方式。如果其中一个符号拼写错误，对`r/render`的周围调用将高亮显示为失败，而不是下面（有时是10s或100s行以下的特定符号）（如在我在工作的一些代码库中看到的那样：:grimacing:）。

我还可以看到，在处理不匹配的分隔符错误时，这也会很有用。现在，如果你说`(some-fn ... [a b c)`并且在开方括号和闭圆括号之间有空行，错误将指向闭圆括号。如果所有括号都携带位置数据，则错误可以说“在 (example.clj:N:M) 读取源时语法错误。未匹配的分隔符：)。期望]与 (example.clj:X:Y) 中的 [ 匹配”

---

我还忘了提，这对于宏编写者来说也很有用，他们可以使用非列表上的位置数据来编写有信息的错误消息。我偶尔看到有人哀叹宏会丢弃位置数据，这将有助于改善这种情况。

---

我也非常感兴趣这个特性。我希望在与 `clojure.lang.Compiler/analyze` 结合使用时使用它来找到给定Clojure形式中局部绑定的所有使用情况，在Clojure编辑器中，突出显示所有这样的使用情况，并允许用户重命名绑定及其所有使用情况。

目前，我必须依赖于 clojure.tools.reader 为每个读取形式分配行和列号。

除此之外，我认为此功能将启用其他有用的静态分析和错误报告功能。

就我的用例而言，至少，如果这是 `read` 的一个可选功能，默认情况下是关闭的，那就足够了。