使用来自 clojure.core.logic 的所有功能扩展 cljs.core.logic

Question

我一直在工作的代码仓库在这里： https://github.com/aamedina/cljs.core.logic

我基本上是按照 clojure.core.logic 中的代码布局完全逐字逐句进行的，弥补了 ClojureScript 的必要性，将宏移动到了姐妹 .clj 文件中。我对每个文件组织宏的最佳方式没有强硬的意见，我所做的只是我觉得最容易的方式，因为这样您就不必对引用姐妹 .cljs 文件中函数的任何引用语法形式的命名空间进行合格。

此外，我还用 clojurescript.test 将所有 clojure.core.logic 测试进行了移植。

Answer 1

由 adrianm 发表的评论：

因此，我已经更新了代码库，以反映对现有的 cljs.core.logic 代码约定和组织方式的更忠实遵守。我非常欢迎关于如何优化代码以使其在 JVM 上运行更佳的任何见解。

Answer 2

由 dnolen 发表的评论：

你观察到什么类型的性能问题？你运行了哪个特定的基准测试吗？

Answer 3

由 adrianm 发表的评论：

appendo 和 membero 特别慢。

(dotimes (link: i ie5) (run* (link: q) (== q true))) 的执行时间大约为 ~4500ms，约为 JVM 的 10 倍慢。

经过分析，我发现了问题——需要进行相对标准的递归优化，因为代码执行时它正递归地（通过重统一）重新遍历局部变量。例如：
对于 appendo，(run 5 (link: q) (fresh (link: x y) (appendo x y q))) 将扩展成类似的东西...

((_0) (_0 . _1) (_0 _1 . _2) ... ))

而且它很慢，因为每个新的列表实际上都重新遍历了之前所有已统一的局部变量。

我将在周末抽出更多时间来调查这个问题，但我觉得可能只需要简单地不再默认生成唯一的局部变量，因为这样对于统一检查的 identical? 就能捕获所有的尝试遍历。

Answer 4

评论人：munro

我一直在使用 clojure.core.logic 和 cljs.core.logic，并一直在忍受 API 差异。我认为，使用新的阅读条件句，应该废弃 cljs.core.logic 而使用 clojure.core.logic。

cljs.core.logic 是否有特定实现使其在 JS vms 上性能良好？仅仅从代码上看，它看起来相当不同，所以这些性能问题也可能是由不太优化的算法引起的。

我可以帮助调查使 clojure.core.logic 可移植，虽然我对 clojure 比较新手。我的策略是添加阅读条件句，直到测试套件在 clojurescript 中通过。

Answer 5

参考资料：https://clojure.atlassian.net/browse/LOGIC-144（由 adrianm 报告）