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

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

0 投票
规范
很有必要拥有描述规范形式的规范,这样就可以从一个像 (s/keys :req [::a ::b] :opt [::c]) 这样的规范形式转换到一个符合版本,从而可以捕获部分的元素而不需要解析 s-表达式。这可以通过创建规范来实现,从而允许


user=> (require '[clojure.spec :as s] '[clojure.spec.specs])
user=> (s/def ::aspec (s/keys :req [::a ::b] :opt [::c]))
user=> (def aspec-data (s/conform :clojure.spec.specs/spec (s/form ::aspec)))
user=> (pr aspec-data)
[:form {:s clojure.spec/keys,
        :args {:req [[:key :clojure.spec.specs/a] [:key :clojure.spec.specs/b]],
               :opt [:clojure.spec.specs/c]}}]
user=> (map val (-> aspec-data val :args :req))
(:clojure.spec.specs/a :clojure.spec.specs/b)


*补丁:spec-forms.patch(正在进行中)*

9 个答案

0 投票

由 saulshanabrook 发布的评论

我能帮忙解决吗?我很乐意工作。这对我尝试解析 fspec 中的 :args 和 :ret 的规范很有帮助。

0 投票

由 alexmiller 发布的评论

如您所见,这里已经有一个与此大量工作相关的补丁(以及 Rich 和 Stu的一些早期审查)。目前对此提供帮助最有用的是对其中的不足/开放问题的反馈。

0 投票

由 alexmiller 发布的评论

此外,我需要指出,我不期望在没有最终确定规范表单之前,这个问题得到最终定稿和包含,因为它们仍然可能发生变化。

0 投票

评论者:akiel

在当前的补丁中,除了 s/keys 中的键之外,引用规范的密钥缺失。您应该如何建模这些密钥?一种方法是将 qualified-keyword? 添加为 ::spec 的 or-spec 的第四个选项。然后,::spec 可以在 s/valid?s/conforms/form 等其他规范中用作规范参数。

0 投票

由 alexmiller 发布的评论

嗯,这可能是个好主意。

0 投票
_评论者:akiel_

另一个观察结果是:当前 {{s/and}} 和 {{s/or}} 允许包含没有子句


(defspec clojure.spec.alpha/and (s/* ::spec))
(defspec clojure.spec.alpha/or (s/* (s/cat :tag keyword? :pred ::spec)))


应该对这些有一个明确的意义定义,或者我们应该在这里使用 {{s/+}} 并要求至少有一个子句。对于 and 形式,我们可以定义 {{(s/and)}} 与 {{(s/and any?)}} 相同,并且与 {{any?}} 相同。对于 or 形态,由于 {{s/conform}} 返回带标签的结果,所以使用 {{(s/or)}} 将任何值通过 {{::s/invalid}} 作为结果返回,这使得空的 or 形态变得毫无意义。
0 投票

由 alexmiller 发布的评论

这些已有明确的意义定义——它们与 clojure.core/and 和 clojure.core/or 相同。据我所知,这一切都是正确的。

0 投票

评论者:akiel

谢谢。我明白了。在 {{clojure.core}} 文档中定义,{{(clojure.core/and)}} 返回 {{true}},而 {{(clojure.core/or)}} 返回 {{nil}}。

0 投票
参考资料:https://clojure.atlassian.net/browse/CLJ-2112(由 alexmiller 报告)
...