欢迎！请参阅关于页面以了解更多有关此工作的信息。
评论者：glchapman
我稍微查了一下：{{nth-permutation-distinct}}将调用它的{{l}}参数上的{{nth}}。集合不支持{{nth}}，因此更好的集合支持需要修改该函数。
评论者：markengelberg
请参阅这里的讨论：https://groups.google.com/forum/#!topic/clojure/XUEqdCSI6c4
我认为集合作为有效输入不一定合理。这些算法返回的结果高度依赖于元素在seq中的顺序。由于集合是无序的，这种改变将使这些功能不再是纯函数，也就是说，它们可能对于相同的（相等的）输入返回完全不同的输出。这是因为比较为相等的两个集合在应用seq时可能返回不同的元素顺序。这可能会破坏人们在其功能中调用这些集合时所做的测试用例。
我认为用户最好直接应用seq，而不是隐式地这样做，这样他们可以考虑到后果，也许进行某种形式的排序，以确保一致的输出。
评论者：nathan
无论是否有修复，至少需要一个对文档字符串的编辑。
就目前而言，组合将正常工作，直到遇到长度为1的角落情况。像这样的隐藏地雷需要一些修复。强迫对排序问题采取行动将涉及抛出异常、弹出一个警告或在集合上使函数错误持续化。
我同意当前的行为是不友好的。可能的解决方案有
1) 隐含对所有输入调用seq（缺点：不再是纯函数）2) 在集合上抛出错误（缺点：增加了运行时检查）3) 在文档字符串中添加说明，指出输入必须是序列（缺点：需要阅读文档字符串才能理解约束，每个人都知道“序列”是什么吗？集合和映射不满足这个条件？）4) 将这一点的讨论添加到README中（缺点：谁会读README？）
我倾向于选择3或4。我很乐意做出这样的改变。
思考第1点，对于除了长度为1的组合之外的任何事情，行为都不会比现在更不纯。它将与seq、vec、map或任何其他保持顺序的功能具有完全相同的纯度。（map inc some-set）在顺序上也有相同的警告。由于隐藏顺序数据结构和保持顺序（揭示？）函数的相等性问题比组合函数要大得多，因此适当的相等性警告应该与隐藏顺序的对象本身相关。
思考邮件列表上的讨论，人们使用集合的一个原因是故意忽略顺序。我认为最好的建议是在测试之前将序列转换回集合。（set (map inc some-set)）
我认为，如果我们不会让map在集合上损坏，这里的修复是值得的。
我看到了一些与组合相关的问题。数学组合是无序的；但是这些是列表。对于相等性测试，您将使用：（set (map set (combinations some-set n)））
目前，我已在README文件的使用说明的最上方添加了一条注释。对于集合，真正的问题在于对distinct的调用，因此如果Clojure对distinct的代码进行修改，使其可以用于集合（这似乎是一个微不足道的更改），则可以移除此注释。
distinct
