nafc不适用于更复杂的目标

Question

否定作为失败约束{{nafc}}应该只在关系及其参数失败时才成功。测试用例仅覆盖非常简单的案例，例如{{(nafc == q 'b)}}，这在很大程度上等同于(!= q 'b)（至少按我的理解）。但面对稍微复杂一些的情况，它似乎就不再工作了。

示例

`
(run* [q]
(fresh [a b]

(== q (list a b))
(fd/in a b (fd/interval 1 3)) ;; fd is an alias for clojure.core.logic.fd
(fd/< a b)
(nafc membero 2 q)))

;=> ((1 2) (2 3) (1 3))
`

约束指定数字2不应该包含在列表{{q}}中，但仍然包含在内。我原本期望在这里得到唯一的答案{{(1 3)}}。

Answer 1

由：tsdh发表的评论

这个问题似乎可能特定于{{clojure.core.logic.fd}}。至少这个示例可以工作

`
(defn answero [x]
(conde
[(== x :yes)]
[(== x :no)]
[(== x :maybe)]
[(== x :dont-know)]))

(run* [q]
(fresh [a b]

(== q (list a b))
(everyg answero q)
(nafc membero :maybe q)
(nafc membero :dont-know q)))

;=> ((:yes :yes) (:yes :no) (:no :yes) (:no :no))
`

Answer 2

由：nberger发表的评论

这不是错误，这是期望的行为，因为不是nafc目标的所有参数都是具体的。

来自nafc文档字符串

bq. 实验：否定作为失败约束。目标c的所有参数都必须是具体的。如果某些参数不是具体的，则此约束的执行将被延迟。

在使用fd的示例中，q不是具体的（因为a和b不是具体的），所以这几乎等同于nafc不存在。

Answer 3

由：tsdh发表的评论

我对该文档字符串的解释是，检查将被延迟到变量成为基的状态点。在我的第一个例子中，最终 q 变为基。我的意思是，否则 nafc 将非常无用。

Answer 4

参考资料：https://clojure.atlassian.net/browse/LOGIC-172 （由tsdh报告）