关于core.specs.alpha中的clojure.core的完整规范

Question

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

能否将其扩展以包含在clojure.core中定义的所有函数？或许还可以有一个包含这些规范的另一个可选命名空间？我想拥有这些规范对于训练新的Clojure程序员和捕捉错误将非常有帮助。

Answer 1

我们目前没有计划为core中的函数添加规范。规范对于描述语法（主要是宏，我们可能会继续添加）或信息类型（带有键等的映射）最有用。对于泛型和高级函数，可能会尝试编写非常详细的规范，但这些规范很可能在遇到核心中积极通用的或多态函数的添加时被破坏。此外，当使用大量规范化的函数时，确实会有性能影响，由于Clojure程序通常使用相对较少的函数，这种性能影响会被放大。

对于规范2与函数集成的一些正在考虑的事项可能会使得我们可以对高级函数说更多有趣的事情，或许这将在未来的某个时刻改变我们的兴趣平衡。

以上都是这样说的，核心规范的非官方社区仓库位于https://github.com/borkdude/speculative，它们大体上是合理的（但仍然会落入上述问题）。如果您将所有这些内容全部启用，就可以亲自体验性能问题。

Comments

因此，我认为提到工具可能是我方的一个错误。我想象的更好的用例是更高级的静态代码分析。我来自TypeScript背景，在那里人们会避免创建高度详细类型，而是用类型部分描述他们代码库，但将此类内容上传到VSCode内建的TypeScript语言服务器时，就能产生巨大价值！Clojure最近大幅改进了其静态分析工具，如clj-kondo。如果这些工具可以访问clojure.core的任何部分规范，它们就可以在零性能影响的情况下向开发者提供大量信息。您甚至可以利用一个简单的指代任何事物的“any”规范，在规范中保持这种 generics 和 polymorphic 条件的级别。

---

kondo 已经有这个功能了吗？

---

其实并没有，完全不行。kondo的类型检查系统有点拼凑。例如，每次需要进行条件类型检查时，它都必须放置一个自定义函数。

当调用 core.into 时，Kondo 使用一个自定义函数来确保返回类型与作为第一个参数传入的集合类型相同。目前已经在他们的 JIRA 票据板上创建了一个任务，计划将其添加到另一个函数中。然而，这种方法并没有应用于包括 inc 函数在内的许多其他函数。例如，如果你向 inc 函数传入一个 int，Kondo 将无法确定输出是否仍然是 int。

也就是说
以下代码：(nth [1 2 3] 1.5) 在 kondo 中引发错误（但实际上 nth 函数是针对非整数定义的）。
但以下代码 (nth [1 2 3] (inc 0.5)) 执行时没有发生错误。

如果这种情况继续下去，Kondo 将不得不包含大量的逻辑，而这些逻辑并不一定属于其代码库。

如果用户希望实现或扩展这种逻辑，将非常困难。目前尚未有一种简单且易于理解的方法来定义它。我原本希望 spec 能够发展成为一个标准，让开发者能够在 TypeScript 风格下在各自的代码库中编码必要的数据类型逻辑。例如，如果在一个代码库中定义的集合是一个整数的集合，或者针对数据库的某种自定义类型集合，这样的信息将被传达给 Kondo，并能够对其进行逻辑处理。如果后续步骤中有任何错误发生，它也能够预知。Spec 和 Malli 已经具备一些完成这一过程的系统，但 Kondo 缺乏实现这一目的所需的逻辑。

我不确定这种分析的正确逻辑应属于 Kondo 本身，还是应在 Clojure 代码库的某处实现，因为它完全依赖于 Clojure 的 API。我也不确定 spec 或 spec2 是否是存放它的适当位置。这就是为什么我在这里提出这个问题的原因。