请分享您的看法,参加2024 年 Clojure 状态调查!

欢迎!有关如何使用本服务的更多信息,请参阅 关于 页面。

0
core.logic

我正在使用的仓库在这里:https://github.com/aamedina/cljs.core.logic

我几乎逐字照搬了 clojure.core.logic 中的代码布局,以适应 ClojureScript 的必要性,将宏移动到姐妹 .clj 文件中。我并没有关于如何为每个文件组织宏的最佳方法的硬性看法,我所做的是找到最容易的方式,因为这样你就不必为引用姐妹 .cljs 文件中函数的所有引用句法的命名空间进行资格验证。

此外,我还用 clojurescript.test 将所有 clojure.core.logic 测试移植过来。

5 个答案

0

由 adrianm 发布的评论

因此,我已经更新了仓库,以反映对现有 cljs.core.logic 代码约定和组织结构的更加忠实的遵循。我非常欣赏任何有关如何潜在地优化代码以使其在 JVM 上的运行更佳的建议。

0

由 dnolen 发布的评论

你观察到了哪些性能问题?你运行了哪些特定的基准测试?

0

由 adrianm 发布的评论

Appendo 和 membero 非常慢。

(dotimes (link: i ie5) (run* (link: q) (== q true))) 约耗时 4500ms,比 JVM 慢约 10 倍。

经过分析,我发现问题在于——需要相当标准的递归优化,随着代码的执行正反递归地重新遍历(通过重新统一)lvars。例如,
对于 appendo,(run 5 (link: q) (fresh (link: x y) (appendo x y q))) 将展开成类似的东西...

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

而且它很慢,因为每个新列表实际上都会再次遍历之前统一的所有 lvar。

我将在周末有空余时间进一步调查这个问题,但我想这可能是简单地不默认生成唯一的 lvars,因为那时相同的用于统一检查的国家应该可以捕捉到任何尝试的遍历。

0

评论者:munro

我一直在使用 clojure.core.logic 和 cljs.core.logic,并在 API 差异上遇到了困难。对于新的读取条件,我认为应该弃用 cljs.core.logic 以便使用 clojure.core.logic。

cljs.core.logic 有特定的实施方式以在 JS vms 上实现性能吗?仅看代码,它看起来相当不同,所以这些性能问题也可能是由未优化算法引起的。

虽然我对于 clojure 相当新手,但我可以帮助研究使 clojure.core.logic 可移植。我的策略是添加读取条件,直到测试套件在 clojurescript 中通过。

0
参考:https://clojure.atlassian.net/browse/LOGIC-144 (由 adrianm 报告)
...