我一直在研究绳索作为Data.Text的替代方案，我喜欢我所看到的以至于我现在强迫提出这个问题....是否有任何情况下Data.Text会是更好的选择吗？
以下是引导我这一点的观点（如果我对其中任何一个出错，请纠正我） -
内部单个节点绳索 （几乎）与Data.Text对象相同。单节点绳索与文本的开销很小，只是用于区分分支或叶子的单个位标志。如果你真的想要Data.Text，只需使用未分裂的绳索。
复杂性在绳索插入/删除（log（N）vs N）中普遍相同或更好，按索引获取（log（N）/ N取决于树的深度与N）。
我读过绳索的成功证明是c中的混合包，因为线程安全代码损害了性能。然而，这些问题在不可变的Haskell中无关紧要。事实上，在我看来，由于这个原因，Haskell和绳索是彼此的理想选择。
再次，就像我之前的类似问题一样，我对结构的抽象质量更感兴趣，而不是当前的情况（库使用，代码的强化程度等）。如果你明天重写了Haskell库，你会用Data.Rope代替Data.Text吗？
答案 0 :(得分：8)
打包阵列＆＃34;手指树＆＃34;虽然我担心不断的开销，但它似乎是一个很好的表示选择。使用积极的流式激情和其他一些短字符串优化的努力可能会解决这个问题，但Data.Rope缺少这些功能。现在Data.Rope实际上不是Data.Text替换网。
Data.Text背后有巨大的工程努力，经过高度优化，众所周知且记录良好答案 1 :(得分：0)
很久以前，当我尝试使用Rope时，作者告诉我它还没有用，它只是一个实验。 Hackage的一个问题是难以了解哪些软件包/版本真正适合生产。
Rope是否与Data.Text一样兼容Unicode？