不要转换带有：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 提交）