core.logic中逻辑变量搜索特性bug

Question

示例

user> (def tmp {\a 1})
{\a 1}
user> (logic/run* [q] (logic/featurec tmp {\a q}))
(1)
user> (logic/run* [q] (logic/fresh [x] (logic/== x \a) (logic/featurec tmp {x q})))
()

第一个逻辑搜索符合预期。第二个应该返回与第一个相同的结果，但反而失败了。

在core.logic中有关于在fresh模式下特征c的其他模式的测试，即在：(logic/featurec {x q} tmp)。但另一方面，这种模式似乎并不普遍有效。

建议我在此处发表，因为我无法创建一个访问Jira的账户来报告此bug。

Answer 1

已记录为https://clojure.atlassian.net/browse/LOGIC-191

Answer 2

featurec 不能将逻辑变量（顶层或非顶层）作为键。

作为处理具有逻辑变量键的映射的条件，你必须能够处理包含逻辑变量的集合（不仅处理集合数据结构，还要理解集合的逻辑），而 core.logic 没有相关的代码，因此它既不能处理集合的逻辑操作（https://clojure.atlassian.net/browse/LOGIC-56 由删除核心逻辑对集合的支持来解决，因为这不符合逻辑）也不能将逻辑变量作为映射键。

处理集合是处理映射键的前提，因为映射中的键是一个集合。

Comments

这看起来与 featurec 的文档有所混淆，该文档指出：

> fs 必须部分实例化 —— 也就是说，
> 它可能包含作为支持特征提取的值
> 的逻辑变量。

我看到文档明确提到了值。也许它也应当说明 *键* 不能是逻辑变量，以避免混淆。

---

文档不太理想，它假定你对 minikanran 和逻辑编程的术语非常熟悉。

如果你看这些关于 Prolog 中“特征结构统一”的文档 https://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node84.html#l11.sec.fs.prolog，你可以看到它们使用不正当的列表来谈论事物，其中 car 是一个原始项，cdr 是一些逻辑变量，这可以看作是一种映射，如果你构建这些结构的关联列表，那么这种映射将具有非逻辑变量键但值可以是逻辑变量的键，这正是 core.logic 的 featurec

我对逻辑编程术语不是很熟悉，没有读过《Reasoned Schemer》，也不知道core.logic的特徵背后的真实起源故事，但我花了一些时间研究如何在core.logic中添加集合推理，所以我可以肯定它没有这个功能，我知道它对于一般键的统一是必须的。