不要转换带有 :no-transform 元数据附加的表单

Question

core.match 子句与 core.async 转换之间的交互是不受欢迎的。core.async 应该尊重一些钩子，以便某些形式保持不变。例如

(match [x y] [1 2] ... [3 4] ...)

为 {{[1 2]}} 和 {{[3 4]}} 生成的所有代码都将附加此元数据。

Answer 1

评论由：richhickey 提出

你能更具体一点吗？这似乎不是一个好主意，我很好奇为什么会想要这样做。

Answer 2

评论由：dnolen 提出

为了说明 core.async 与像 core.match 这样的库之间的交互是多么糟糕，考虑以下情况

`
(defn foo [e]
(match [e]

[{:type :mouse :client-x x :client-y y}] [x y]
[{:type :mouse :page-x x :page-y y}] [x y]
[{:type :touch :page-x x :page-y y}] [x y]
[{:type :key :char-code c}] c))

`

在没有 core.async 的情况下，core.match会为这种典型的 core.match 使用方式生成合理的代码量，以有效地匹配映射 - 大约 230 行漂亮的打印的 JavaScript。

但是，如果用户将这种典型表达式包裹在一个 go 块中

`
(defn foo [in]
(go (while true

    (let [[e c] (<! in)]
      (match [e]
        [{:type :mouse :client-x x :client-y y}] [x y]
        [{:type :mouse :page-x x :page-y y}] [x y]
        [{:type :touch :page-x x :page-y y}] [x y]
        [{:type :key :char-code c}] c)))))

`

它生成了近 4200 行漂亮的打印的 JavaScript。我没能看到 core.async 转换由 core.match 生成优化的条件表达式的价值，它只是生成了 18 倍多的代码，额外生成的代码明显是无用的 - 用户是在匹配一个值，他们不能在模式中放任意计算。

https://gist.github.com/swannodette/7723758

Answer 3

评论由：metametadata 发表

我仍然遇到这个问题，不得不使用来自https://github.com/emezeske/lein-cljsbuild/issues/303的{{:jvm-opts}}解决方案。在我的情况下，StackOverflow似乎也和{{is}}以及{{core.async}}和{{try-catch}}有关。

Answer 4

参考： https://clojure.atlassian.net/browse/ASYNC-40（由dnolen报告）