core.specs.alpha 中对 clojure.core 的完整规范

Question

目前，core.specs.alpha 只包含一些基本特殊形式和宏的规范。

能否将其扩展到包括 clojure.core 中定义的所有函数？或者，也许可以有一个包含这些规范的另一个可选命名空间？我想，这些规范对于培训和捕捉错误可能非常有用。

Answer 1

我们不打算为 core 中的函数添加规范。规范最有用之处在于描述语法（大多是宏，我们可能还会继续添加）或信息类型（包含键等的映射）。对于通用和高级函数的诱惑是尝试编写非常详细的规范，这些规范很可能会在核心的泛型或多态函数的有效添加面前破裂。此外，使用大量规范函数的时候，的确会造成性能冲击，由于 Clojure 程序倾向于频繁使用相对较小的几个函数，这种性能冲击被放大。

关于规范 2 与函数的集成有一些正在考虑的事情，这可能会使人们能够对高级函数说更多有趣的事情，也许在未来的某个时候这会改变这里的兴趣平衡。

尽管如此，有一个关于 core 规范的非官方社区库位于 https://github.com/borkdude/speculative，它们大体上是合理的（但仍存在上述问题）。如果您使用所有这些工具进行工具化，您可以亲身体验性能问题。

Comments

所以，我认为提到仪器可能是我的一个错误。我原先是在想象一个更高级的静态代码分析。我来自 TypeScript 背景，那里的人会避免创建你所说的详细类型，而是用类型部分描述他们的代码库，但当你用 VSCode 中内置的 TypeScript 语言服务器处理它时，它会产生大量价值！Clojure 最近大幅改进了其静态分析工具，如 clj-kondo。如果这些工具能够访问 clojure.core 的部分规范，它们将对开发者提供大量的信息，而不会对性能产生影响。你甚至可以采用一个简单的 'any' 规范，它仅仅引用任何事物，你可以在规范中保持通用品类和类型的多态性。

---

酒已经在进行中了吗？

---

事实上，并不是这样，也不是完全的。kondo 的类型检查系统有些拼凑。每次做条件类型检查时，都不得不输入一个自定义函数，例如。

对于 core.into，kondo 有一个自定义函数，表示返回类型应与作为其第一个参数传入的集合类型相同。已经在他们的 JIRA 票据板上创建了一个任务，将其添加到另一个函数中，而且它不适用于其他一些函数，比如函数 inc。如果你给 inc 传递一个 int，Kondo 就不知道输出是否仍然是 int。

I. E.
此代码：nth [1 2 3] 1.5 在 kondo 中抛出一个错误（顺便说一下，这是不正确的，nth 对于非整数是定义好的）
但是这段代码（nth [1 2 3] (inc 0.5)）运行没有报错。

如果这种情况持续下去，Kondo 最终可能需要包含大量的逻辑，这些逻辑不一定属于他们的代码库。



我不确定进行这种分析的正确逻辑是否应该在 Kondo 本身，或者是否应该位于 Clojure 代码库的某个部分，因为它完全依赖于 Clojure 的 API。我也不知道 spec 或 spec2 是否是存放它的合适位置。这就是为什么我在这提出了这个问题。