2024 年 Clojure 调查问卷! 中分享您的想法。

欢迎!请查看关于页面,以获取更多关于此如何工作的信息。

0
Spec

在我为自己的库进行spec过程中,遇到了一个使用 s/unforms/? 的问题,我认为这个行为有点奇怪。

(require '[clojure.core.specs.alpha :as cs])

(def binding-form '[a b :as c])

(def x (s/conform ::cs/seq-binding-form binding-form))
;; x => {:forms [[:local-symbol a] [:local-symbol b]], :as-form {:as :as, :as-sym c}}

(s/unform ::cs/seq-binding-form x) 
;; => (a b (:as c))

(s/valid? ::cs/seq-binding-form (s/unform ::cs/seq-binding-form x))
;; => false

这是预期行为吗?根据直觉,我原本预期第一次unform会生成原始形式,并且unform的结果会通过(使用相同的spec)进行验证。

1 答案

0

已选择
 
最佳答案

可能有一两点需要注意。正则表达式形式解析顺序集合(重要的是列表和向量),但没有保留原始集合类型并将其unform到正确类型的途径。这是一个通用问题,对于conform、unform和gen的所有方面都没有简单的解决方案。我们没有计划在spec 1中解决这个问题。在spec 2中,我们现在通过s/catv和s/cats支持这一点,它们是特定类型的变体。

关于(:as c),我认为这是一个已知的使用尾随? conform的bug,但需要一段时间才能找到链接。

啊,确实有一个错误报告: https://ask.clojure.org/index.php/2418/nesting-cat-inside-causes-unform-to-return-nested-result?show=2418#q2418

我没有看到这个。这回答了我的问题。

至于catv,catc - 很好,我知道它们对于宏/dsl情况来说会很实用。
...