不支持更复杂的目標

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. EXPERIMENTAL: 否定作为失败约束。目标c所有的参数都必须是ground的。如果某个参数不是ground的，则该约束的执行将被延迟。

在使用fd的例子中，q不是ground的（因为a和b不是ground的），因此这与nafc不存在几乎相同。

Answer 3

评论由：tsdh

我对该文档字符串的解释是，检查将被延迟，直到变量成为基本点。最终，在第一个例子中，{{q}}） become ground。我的意思是在其他情况下，{{nafc}}可能会非常无用。

Answer 4

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