Rich在Clojure历史中说：
我认为转换器是一个基本的原语，它将关键逻辑与列表/序列处理和构建解耦，如果我能重新设计Clojure的话，我会把它们放在最低层。
这让我很感兴趣，我真的很好奇以转换器为先的Clojure会是什么样子？我并不真的期待Rich在这里回答（我应该在他的HOPL演讲时问这个问题...）但是也许更接近核心的人可能会有一些见解。
我希望能看到一个Clojure，其中转换器是默认且最容易的解决问题的方式，所有教程、高亮显示和周围的示例代码都使用它们，而一个上下文（向量、惰性、第一个等）仅在边缘被选择。目前来说，编写惰性代码比转换器代码更容易（但可能不是更简单）。
我在想，以转换器为先的Clojure是否会解决上述问题，或者它主要是否是关于类似clojure.core的底层。
对于我个人来说，我必须积极对抗惰性——我不认为在我们的代码库中有任何好处，但由于它是编写Clojure的最简单方法，我必须额外努力，不要偶然进入惰性世界，以及要在他人的PR中找到这些模式。
我希望能有一个clojure.core2，其中转换器是默认的，编写转换器代码很容易，可能需要较少的输入/仪式，例如comp和into []等。进入惰性世界总是一种选择，就像Clojure中不纯的部分——stm、transients等。我不完全确定这样一个核心库会是什么样子，但这确实是我很想尝试的。
此外，还有一些特定的转换器优化，如https://github.com/cgrand/xforms#on-key-value-pairs可以考虑。也许还可以将map的多种可处理性作为转换器的一部分使用。
可以在函数中提供对xform参数的原生支持，这些函数当前需要一个集合来预处理它们，如run!和str/join——如果你积极使用转换器，你就会开始注意到像'嘿，我甚至不需要一个集合那里'这样的东西，并开始寻找不同的转换器上下文——所以（count (into [] xform input)）将变为（x/count xform input）。
