请分享您的想法:2024 Clojure 状态调查!

欢迎!请查阅关于页面了解有关工作方式的更多信息。

+1
Spec
使用由某些{{cat}}嵌套在某些{{?}}中的spec调用{{conform}}和{{unform}}会在结果中创建额外的嵌套层级


(require '[clojure.spec :as s])

(let [spec (s/? (s/cat :foo #{:foo}))
      initial [:foo]
      conformed (s/conform spec initial)
      unformed (s/unform spec conformed)]
  [initial conformed unformed])
;;=> [[:foo] {:foo :foo} [(:foo)]]


仅使用{{?}}或{{cat}}本身不会有这种行为


(let [spec (s/? #{:foo})]
  (s/unform spec (s/conform spec [:foo])))
;;=> [:foo]

(let [spec (s/cat :foo #{:foo})]
  (s/unform spec (s/conform spec [:foo])))
;;=> (:foo)


*补丁:* CLJ-2003-corrected.patch

10 个答案

0

评论者:pbrown

我还遇到另一种情况,当重复一个或多个序列并在开始或结束时包含一个可选元素,并且该元素的谓词也匹配另一端的元素时,会出现额外的嵌套

user=> (s/conform (s/+ (s/cat :k any? :v (s/? any?))) [:a 1 :b 2]) [{:k :a, :v 1} [{:k :b, :v 2}]]

我期望的是

`[{:k :a, :v 1} {:k :b, :v 2}] `

以下给出了预期的结果

user=> (s/conform (s/+ (s/cat :k any? :v (s/? any?))) [:a 1 :b]) [{:k :a, :v 1} {:k :b}] user=> (s/conform (s/+ (s/cat :k keyword? :v (s/? int?))) [:a 1 :b 2]) [{:k :a, :v 1} {:k :b, :v 2}] user=> (s/conform (s/*

0

由 alexmiller发表的评论:

Phil,我认为您的示例是不同的问题,您应该为该问题提交一个新的Jira。

0

由 alexmiller发表的评论:

好吧,也许我会收回刚才的话,它们可能有关联。

0

由 bbloom发表的评论:

我只是试图理解一些定义表单,以下是一个示例

user=> (s/unform :clojure.core.specs/defn-args (s/conform :clojure.core.specs/defn-args '(f (link: & xs))))
(f ((& xs)))

0

[email protected]发表的评论:

这看起来就是所有需要的。

0
_由 favila_发表的评论:

问题实际上比 {{(? (cat ...))}} 更普遍。当子操作是正则表达式时,{{s/unform}} 的一个 {{s/?}} 会引入额外的嵌套层次。当子项是正则表达式时,我们应该消耗同样的“级别”的序列,因此 unform 不应引入额外的层次。然而在其他情况下(非正则表达式操作),我们仍然可能生成一个嵌套的集合。

上一个补丁过于激进:它会解除 {{s/?}} 下的所有子 unform。这个补丁 CLJ-2003-corrected.patch 只在子操作是正则表达式时才解除。

不幸的是,区分期望但可选的 nil 和来自 {{s/?}} 的非匹配项是不可能的。特别是以下测试现在成立


(testing "s/? 匹配 nil"
  (is (nil? (s/conform (s/? nil?) [nil])))
  (is (nil? (s/conform (s/? nil?) [])))
  (is (nil? (s/conform (s/? nil?) nil)))
  (is (= (s/unform (s/? nil?) nil) [])))


(我没有将这些测试添加到补丁中,因为我不确定它们是否应该是 unform 合同的一部分。但是,它们确实是很大的陷阱。)

我还对{{s/?}}的每一个可能的子操作添加了测试,除了{{::s/accept}},因为我没想出相应的测试用例。 (我不确定{{::s/accept}}是否真的在{{s/op-unform}}内部可达?)
0

由 alexmiller发表的评论:

感谢对此工作 - 当我有机会时我会看的。

0

评论者:favila

我必须稍微修改我的补丁(相同的名称):其中一个测试用例没有测试正确的东西。

0

评论者:favila

由于其他提交中添加的测试而不能再干净地应用到master分支上,补丁已重新应用

0
参考: https://clojure.atlassian.net/browse/CLJ-2003(由alex+import报告)
...