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目标的不是所有参数都是ground的。

从nafc文档字符串：

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

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

Answer 3

由tsdh发表的评论：

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

Answer 4

参考：[https://clojure.atlassian.net/browse/LOGIC-172](https://clojure.atlassian.net/browse/LOGIC-172)（由tsdh报告）