跨命名空间中的letfn冲突

Question

如果你的两个命名空间中有相同名称的fn使用letfn，将会使用错误的fn。

`
(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的表达式和语句形式包裹在函数声明中（以前，只有表达式形式被包裹）。

我只进行了最小的测试。它修复了描述中的代码。

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

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 "应为 4-> " (f1))
(println "应为 5-> " (f2))
`

然后访问 scripts/repl.

结果为

`
cljs.user=> (load-file "letfn_bug/core.cljs")
应为 4-> 5
应为 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,"应为 4-> ",letfn_bug.core.f1.call(null)); cljs.core.println.call(null,"应为 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等是否仍然适用于此模式。

另一个选择是跟踪此模式和将其分配到命名空间+阴影逻辑中（即在同一个命名空间中多次使用相同名称）。

Answer 9

_由 jeremyrsellars 发表评论_

以下是针对 Wrap-top-level-letfn-to-avoid-collisions 补丁的最新更新，目前版本为 r1.10.520。

我无法想到测试死代码消除的方法，但我们预计此高级编译的输出应包含“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)]  ; 此函数和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](https://clojure.atlassian.net/browse/CLJS-1965)（由 jeremyrsellars 报告）