不要转换带有: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](https://clojure.atlassian.net/browse/ASYNC-40)（由dnolen报告）