在更复杂的目标下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时，因为a和b不是基础的，所以q不是基础的，所以它与没有nafc几乎是一样的。

Answer 3

评论由：tsdh发表

我对文档字符串的解释是，检查将被延迟到变量成为地面状态的时间点。最终，在我的第一个例子中，{{q}} 变成了地面状态。我的意思是，否则 {{nafc}} 几乎没有用。

Answer 4

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