所有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]
:. 作为选项}
:. 最长静态键值 final-very-long-key} d]
        * ...)

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

这可以改为 `编译时语法错误，位置在 (example.clj:6:30)`，因为那里有 `d`。

另一个例子是 hiccup 语法，这是一种流行的 HTML 编写方法，主要使用向量和国标字。有些库如 Reagent 对于以符号开头的向量处理方式不同。如果其中一个符号拼写错误，`r/render` 周围的调用将被突出显示为失败，而不是具体的符号，有时候这个符号可能位于下面 10 行或 100 行（正如我在一些代码库中看到的那样：:grimacing:）。

我也认为这个功能在处理不匹配的分隔符错误时会有用。目前，如果你说 `(some-fn ... [a b c)` 并且括号之间有空行，错误会指向闭合的圆括号。如果所有括号都带有位置数据，则错误可以说明 “语法错误在读取源时 (example.clj:N:M)。不匹配的分隔符：)。期望 ] 与 [ 匹配在 (example.clj:X:Y)”

---

我还提到这对于宏编写者同样有用，他们可以使用非列表上的位置数据来编写有用的错误消息。我偶尔看到有人抱怨宏丢弃位置数据，这将有助于改进这种情况。

---

我也非常感兴趣这个特性。我想结合使用 `clojure.lang.Compiler/analyze` 来找到一个 Clojure 表达式中的所有局部绑定的使用，在 Clojure 编辑器中突出显示这些使用，并让用户有可能重命名绑定及其所有使用。

实际上，我不得不依赖 `clojure.tools.reader` 为每个读取表达式分配行和列号。

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

至于我的使用案例，至少，如果这是 `read` 的一个可选特性，默认情况下是关闭的，那就足够了。