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