核心.specs.alpha 中的 clojure.core 全规格

Question

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

能将其扩展到包含 clojure.core 定义的 所有函数吗？或者，也许可以有一个可选的命名空间来包含这些规范？我设想，如果这些规范可用，将非常有助于训练新的 Clojure 程序员和错误捕捉。

Answer 1

我们不打算添加 core 中函数的规范。规范主要适用于描述语法（主要是宏，我们可能会继续添加），或者信息类型（有关键等的映射）。对于泛型和高阶函数的诱惑是尝试编写非常详细的规范，这些规范在 core 中对这些积极主动的泛型或多态函数的添加面前很可能会被破坏。此外，当使用大量规范函数时，确实会有真正的性能影响，由于 Clojure 程序倾向于频繁使用相对较小的函数数，这种性能影响被放大了。

对于规范 2 函数集成正在考虑的各种事情，这可以使更高阶函数说出更有趣的事情，或许在未来某个时候这会改变这里的兴趣平衡。

虽然如此，核心规范的非官方社区库位于https://github.com/borkdude/speculative，它们在很大程度上是合理的（但仍存在上述问题）。如果您打开了所有这些功能，您就可以亲自体验性能问题。

Comments

因此，我认为提到仪器可能是我犯的一个错误。我更想象的是一个更高级的静态代码分析用例。我来自TypeScript背景，人们会避免创建高度详细类型，就像你说的那样，而是用类型部分描述他们的代码库，但当它通过VSCode内置的语言服务器处理时，它会产生大量的价值！Clojure最近大幅改善了其静态分析工具，如clj-kondo。如果这些工具能够访问clojure.core的部分规范，它们可以为开发者提供大量的信息而不影响性能。您甚至可以利用一个简单的“任何”规范，它只引用任何内容，您可以在规范中保留这种通用和多态的条件级

---

不是已经有了kondo吗？

---

其实不然，并不是完全这样。kondo的静态类型检查系统有点像拼凑起来的。例如，每次它需要进行条件类型检查时，都必须插入一个自定义函数。

kondo为core.into定义了一个自定义函数，指定返回类型与作为其第一个参数传入的集合的类型相同。已经在他们的JIRA板上有一个问题单要添加到另一个函数，而且它也不适用于各种其他函数，比如inc函数。如果你向inc传递一个int，kondo就不知道输出是否仍然是int。

IE.
此代码：(nth [1 2 3] 1.5) 在 kondo 中引发错误（不过，实际上 nth 可以用于非整数）
但这段代码 (nth [1 2 3] (inc 0.5)) 会正常执行，没有错误。

如果这种情况持续下去，kondo 将不得不拥有大量逻辑，而这些逻辑并不一定属于他们的代码库。

如果用户想要实现或扩展此类逻辑，这将很困难。没有简单且易于理解的方法来定义它。我原本希望 spec 能够成长并通过 TypeScript 方式的开发者在自己的代码库中编码必要类型逻辑成为一种标准方式。例如，如果您的代码库中需要一个 int 的集合，或者需要一个针对数据库的某种自定义类型的集合，kondo 就会将这些信息传达出去，并能够在这上面执行逻辑，并在执行过程中发现潜在的错误。

我不确定进行这种类型分析的适当逻辑是否应该位于 kondo 中，或者是否应该位于 clojure 代码库中某处，因为它完全依赖于 clojure 的 API。我也不知道 spec 或 spec2 是否是存放它的合适位置。这就是为什么我提出这个问题。