所有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

这可以改为说 `Syntax error compiling at (example.clj:6:30)`，因为这里是 `d` 的位置。

另一个例子是 hiccup 语法，它是使用向量关键词编写 HTML 的流行方法。某些库如 Reagent 会以不同的方式处理以符号开头的向量。如果其中一个符号拼写错误，`r/render` 的调用中的周围代码会被高亮显示为失败，而不是具体符号，有时这个符号可能位于下方 10 行或 100 行（如同我在一些项目代码中所见 :grimacing:).

我在为不匹配的括号制作错误时也看到了这种用法的作用。现在，如果你说了 `(some-fn ... [a b c)`，在打开方括号和关闭圆括号之间有行，错误将指向关闭圆括号。如果所有括号都携带位置数据，则错误可以表述为“Syntax error reading source at (example.clj:N:M). Unmatched delimiter: ). Expected ] to match [ at (example.clj:X:Y)”

---

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

---

我也非常感兴趣这个特性。我希望结合 `clojure.lang.Compiler/analyze` 使用它，以在给定的 Clojure 表达式中找到局部绑定的所有使用情况，在 Clojure 编辑器中突出显示所有此类使用情况，并让用户有机会重命名绑定及其所有使用情况。

就目前的情况而言，我必须依赖 clojure.tools.reader 为每个读取的表达式分配行和列号。

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

就我的使用场景而言，至少，如果这将是`read`的可选功能并且默认关闭，那么就足够了。