2024年Clojure状态调查!中分享您的想法。

欢迎!有关如何使用本站的更多信息,请参阅关于页面。

0
规范

目前,core.specs.alpha只为一些基本特殊形式和宏提供了规范。

它可以扩展以包含clojure.core中定义的所有函数吗?或者,也许可以有一个包含这些规范的其他可选命名空间?我想象到具有这些规范可以很方便地用于训练新的Clojure程序员和捕捉错误。

1 答案

+2

我们目前不打算为核心中的函数添加规范。规范最有用之处在于描述语法(主要是宏,我们预计将继续添加),或信息类型(带有键等的映射)。对于通用和高级函数的诱惑是尝试编写非常详细的规范,这些规范可能会受到核心中积极主动的通用或多态函数添加的影响而破裂。此外,大量使用指定函数时,还存在真实的性能影响;由于频繁使用相对较少的函数,这是Clojure程序倾向于拥有的特征,因此这种性能影响会被放大。

有关规范2集成函数的几个想法正在考虑之中,这将使能够说更多关于高级函数的有趣事情,也许在未来的某个时刻会改变这里的利益平衡。

以上所述,在 https://github.com/borkdude/speculative 上有一个关于核心规范的非官方社区仓库,它们在很大程度上是合理的(但仍然存在上述问题)。如果你将这些全部启用,可以亲身体验性能问题。

by
因此,我认为提到仪器可能是我的一个错误。我设想的一个更好的用例是更高级的静态代码分析。我来自TypeScript背景,在那里人们会避免创建高度详细的基本类型,而是通过类型部分描述他们的代码库,但是当这些通过VSCode内置的TypeScript语言服务器进行时,它可以产生巨大的价值!Clojure最近极大地改进了它的静态分析工具,比如clj-kondo。如果这些工具能访问clojure.core的部分规范,它们可以在零性能开销的情况下向开发者提供大量信息。你甚至可以利用一个简单的指代任何内容的'any'规范,你可以在规范中保持那种通用和多态性条件
by
Kondo不已经有了吗?
by
edited by
并不是,还想完全如此。kondo的类型检查系统有点草率。比如,每当它需要进行条件类型检查时,它必须插入一个自定义函数。

Kondo有一个针对core.into的自定义函数,它指定返回类型与传递给它的第一个参数类型的相同。已经在他们的JIRA板上有一个任务要在另一个函数中添加它,而且它也没有在诸如inc函数等各种其他函数中保持一致。如果你将一个整数传递给inc,Kondo不知道输出是否仍然是整数。

也就是说。
此代码:(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 是存放它的正确位置。这就是为什么我这里提出这个问题。
...