命名空间间 letfn 冲突

Question

如果你在两个命名空间中使用相同名称的 letfn，则会使用错误的函数。

`
(ns hello-world.one)

(letfn [(answer [] "1")]
(defn get-answer []

(answer)))

`

`
(ns hello-world.two)

(letfn [(answer [] "2")]
(defn get-answer []

(answer)))

`

`
(ns hello-world.core
(:require [hello-world.one]

        [hello-world.two]))

(println "one =>" (hello-world_one/get-answer)) ; one => 1
(println "two =>" (hello-world_two/get-answer)) ; two => 1 WHAT?!?
`

此问题似乎存在于顶层 letfn 和非顶层 (let (link: ) (letfn (link: ...))) 中。

Answer 1

评论由：jeremyrsellars 发布

这个补丁在函数声明中包装了 letfn :expr 和 :statement 形式（以前，只有 :expr 形式被包装）。

我只做了最少量的测试。它修复了描述中的代码。

注意：这是我第一次尝试构建编译器，我可能没有完全理解整个问题。

Answer 2

评论由：mfikes 发布

确认此补丁修复了本地主机 ClojureScript (Planck) 中的问题。

未应用补丁

cljs.user=> (require 'hello-world.core) one => 2 two => 2 nil

应用补丁

cljs.user=> (require 'hello-world.core) one => 1 two => 2 nil

Answer 3

评论者：dpsutton

这不需要不同的命名空间。问题是 let-fn 将其绑定作为全局变量。

简单的复现方式为
1. lein new mies letfn-bug,
2. 将 cljs 版本更新到 (link: org.clojure/clojurescript "1.9.946")
3. 然后

`
(ns letfn-bug.core
(:require [clojure.browser.repl :as repl]))

(enable-console-print!)

(letfn [(non-unique-name [] 4)]
(defn f1 [] (non-unique-name)))

(letfn [(non-unique-name [] 5)]
(defn f2 [] (non-unique-name)))

(println "should be 4-> " (f1))
(println "should be 5-> " (f2))
`

然后在 scripts/repl 中。

结果为

`
cljs.user=> (load-file "letfn_bug/core.cljs")
should be 4-> 5
should be 5-> 5
nil
cljs.user=>

`

生成的 js 代码：

// 由 ClojureScript 1.9.946 编译 {} goog.provide('letfn_bug.core'); goog.require('cljs.core'); goog.require('clojure(browser.repl'); cljs.core.enable_console_print_BANG_.call(null); var non_unique_name = (function letfn_bug$core$non_unique_name(){ return (4); }); letfn_bug.core.f1 = (function letfn_bug$core$f1(){ return non_unique_name.call(null); }); var non_unique_name = (function letfn_bug$core$non_unique_name(){ return (5); }); letfn_bug.core.f2 = (function letfn_bug$core$f2(){ return non_unique_name.call(null); }); cljs.core.println.call(null,"should be 4-> ",letfn_bug.core.f1.call(null)); cljs.core.println.call(null,"should be 5-> ",letfn_bug.core.f2.call(null));

Answer 4

评论者：dnolen

快速审查补丁，我们可能最好只在它真正是问题的顶层进行包装，而不是总是包装在语句上下文中。

Answer 5

评论者：gnl

我想提一下，建议提高这个问题的优先级。像这样的编译器打破作用域的问题绝不是小问题。

Answer 6

评论由：jeremyrsellars 发布

这个补丁类似于第一个，但它仅将不在 fn-scope 中的 letfn 表达式的语句包装。 (CLJS-1965-Wrap-top-level-letfn-to-avoid-collisions.patch)

Answer 7

由 timothypratley 发表的评论

我在本地确认新的补丁工作良好......但是我必须手动应用更改，因为 git apply 失败。如果 Jeremy 创建一个全新的补丁，这看起来可以吗？如果我可以以任何方式帮助，请告诉我（如果这样能帮助的话，我很乐意更新他的补丁，以便保持他的信用？）

Answer 8

评论者：dnolen

在顶层封装闭包可能会引入与 Closure 高级的其他不受欢迎的交互 - 在继续进行建议的补丁之前，我想看看 DCE 等 是否仍然适用于此模式。

另一个选择是跟踪此模式并将其分配给命名空间加遮蔽逻辑（即在单个 ns 中多次使用相同的名称）。

Answer 9

_由 jeremyrsellars 发表的评论

以下是关于截至 r1.10.520 的 Wrap-top-level-letfn-to-avoid-collisions 补丁的更新。

我想不出一种方法来用 deftest 测试死代码消除，但我们预计此高级编译输出将包含“kwc”，但不包含“dce”。

{code:title=letfn_dce_test.cljs|borderStyle=solid}
(ns cljs.letfn-dce-test
  (:require [cljs.test :refer-macros [deftest is]]))

(letfn [(fn-to-kwc [] :kwc)
        (fn-to-dce [] :dce)]  ; 此 fn 和 kw 应该由 DCE 消除
  (defn f0 [] (count (str f (name (fn-to-kwc)))))
  (deftest letfn-live-code-test
    (is (pos? (f0)))))


我观察到它的行为就像死代码消除仍然正常工作一样。


bin/cljsc src/test/cljs/cljs/letfn_dce_test.cljs  "{:optimizations :advanced}"|less


David Nolan 的替代方案很有趣。还有更充分的理由去考虑将 letfns 语句附属于命名空间吗？

Answer 10

参考：https://clojure.atlassian.net/browse/CLJS-1965（由 jeremyrsellars 提出）