评论者：alexmiller
我只是想说，这是我第一次记得查看这个工单，因为它很大程度上早于我在Clojure核心中的参与。我知道已经过去了多年，我正在尽力真诚地思考这个问题。但我不太可能在你已经走过的路径上提出一些愚蠢的问题。
我确实赞同让良好的集合特性能够被Clojure核心内外部的实现所使用。
关于更改协议的可行性，我认为可能你在那里误解了我的意图。我们当然可以更改或扩展协议，但我们只需要以成长（保留现有内容）的方式来进行，而不是打破（通过更改现有的方法签名）。我反对的是更改 Sorted.seqFrom() 的签名，因为这会破坏所有现有的实现——这根本不可行。但将 Sorted 扩展到 Sorted2（或任何更有意义的名称）并添加新的 seqFrom 实例数是完全可行的。子序列代码可以对 coll 是 Sorted2 的情况做最好的事，如果只是 Sorted，则回落到其他操作。有各种方法来实现这一点，但希望能理解意图——现有内容不改变继续工作，如果可用，则利用新内容。
回顾一下，seqFrom 和相关功能似乎不足以涵盖可能会跨越不同数据结构的需求。我仍然认为 NavigableSet 有许多很好的前期思考（不是直接说它是答案，但确实是同一个问题领域），并且更广泛地研究在间隔几年间添加的其他数据结构将非常有利，看看我们能够实现什么。
实际上，子序列的实现相当混乱，依赖于许多移动的部分和假设。也许子序列操作实际上应该直接由集合来完成。
