首先，让我们看看一些简单的默认sorted-set行为（它通过PersistentHashSet使用PersistentHashMap，因此使用equals/hashCode来确定身份）
`
user=> (sorted-set [1 2] [-5 10] [1 5])
{[-5 10] [1 2] [1 5]}
而sorted-set-by是通过PersistentTreeMap通过PersistentTreeSet实现的，这意味着提供的sorted-set-by比较器将用于确定身份，因此是集合的成员。这可能导致（据我所知）非直观的行为
user=> (sorted-set-by #(> (first %) (first %2)) [1 2] [-5 10] [1 5])
#{[1 2] [-5 10]}
```
Notice that because the provided comparison fn determines that (link: 1 2) and (link: 1 5) have the same sort order, the latter value is considered identical to the former, and not included in the set. This behaviour could be very handy, but is also likely to cause confusion when what the user almost certainly wants is to maintain the membership semantics of the original set (e.g. relying upon equality/hashCode), but only modify the ordering.
(BTW, yes, I know there's far easier ways to get the order I'm indicating above over a set of vectors thanks to vectors being comparable via the compare fn. The examples are only meant to be illustrative. The same non-intuitive result would occur, with no easy fallback (like the 'compare' fn when working with vectors) when the members of the set are non-Comparable Java object, and the comparator provided to sorted-set-by is defining a sort over some values returned by method calls into those objects.)
I'd be happy to change the docs for sorted-set-by, but I suspect that there are others who could encapsulate what's going on here more correctly and more concisely than I.
