在更复杂的目標下，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](https://clojure.atlassian.net/browse/LOGIC-172) （由tsdh报告）