Rich在Clojure历史中提到
我认为转换器是一个基本的原始操作，它将关键逻辑与列表/序列的处理和构建解耦，如果我可以重新实现Clojure，我会将它们放在最底层。
这让我很感兴趣，我真的很想知道以转换器为先的Clojure会是什么样子？我并不真的期望Rich在这里回答（我应该在他的HOPL演讲中提出这个问题...）但可能更接近核心的人可能有一些见解。
我希望看到一种Clojure，其中转换器是默认且最容易解决问题的方法，所有教程、gists和周围的示例代码都在使用它们，而上下文（向量、惰性、首项等）只选择在边缘。当前编写惰性代码比编写转换器代码更容易。
我想知道以转换器为先的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中 - 如果你积极使用transducers，你会开始注意到一些事情，比如“嘿，我甚至不需要集合”并开始寻找不同的变换器上下文 - 因此，你将不会写(count (into [] xform input))，而是(x/count xform input)
