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 中有一些测试涉及“featurec”在 fresh 模式下的其他模式，即：(logic/featurec {x q} tmp)。但这个模式似乎并不总是正常工作。

有人建议我在这里发表，因为我无法创建可以访问 Jira 以提交此问题的帐户。

Answer 1

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

Answer 2

featurec不能将逻辑变量（有根或无根）作为键

因为需要以逻辑方式处理键为lvars的map，所以你必须能够处理包含lvars的集合（不仅仅处理集合数据结构，还要理解集合的逻辑），但core.logic没有该代码，因此它既不能处理集合上的逻辑（https://clojure.atlassian.net/browse/LOGIC-56曾因为不正确地移除了core.logic对集合的早期支持而被“修复”），也不能处理lvars作为map的键。

处理集合是处理map键的先决条件，因为map中的键是一个集合。

Comments

这似乎对featurec的文档有些误解，该文档表明

> fs必须是部分实例化 - 即，
> 它可以包含值，这些值是逻辑变量，以支持
> 特征提取。

我在文档中明确看到了“值”一词。它们可能还应该声明，*键*不能是逻辑变量，以免引起混淆。

---

文档不是很好，并假设你非常熟悉minikanran和逻辑编程的专业术语。

如果你查看有关prolog中“特征结构统一”的这些文档 https://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/node84.html#l11.sec.fs.prolog，你可以看到它们在错误的列表术语，cons单元（其中car是一个地面项，cdr是一个逻辑变量）的术语中讨论问题，如果你为这些结构建立一个关联列表，这可以被视为一种类型的映射，这种映射的键不是lvars，但值可以是，这就是你得到core.logic的featurec的方式

我对逻辑程序设计术语不太了解，没有读过《Reasoned Schemer》，也不清楚core.logic的特性和真正的历史起源，但我花了一些时间尝试在core.logic中添加对集合进行推理的功能，所以我可以肯定它现在没有这个功能，并且我知道这是在统一map键时的一项基本要求。