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

欢迎!请参阅关于页面了解更多关于该作品的详细信息。

0
Spec
有一个具有描述规格形式的功能的规范将非常有用,这样可以从如clojure.spec/keys的规格形式像 (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的条件或列表中。这样,::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](https://clojure.atlassian.net/browse/CLJ-2112)(由alexmiller报告)
...