Data.Text與繩索

我一直在尋找繩索作爲Data.Text的替代品，而且我喜歡我所看到的如此之多以致於我現在被迫問這個問題....是否有任何情況下Data.Text將是更好的選擇？Data.Text與繩索

下面是導致我這個（糾正我，如果我錯了，對任何這些）點 -

單葉節點繩子內部是（幾乎）同樣的事情作爲Data.Text對象。單節點繩索與文本的開銷很小，只是用於區分分支或葉子的單個位標誌。如果你真的想要Data.Text，只需使用非分離的繩索。
複雜性在繩索插入/刪除（log（N）vs N）中通過相等或更好，通過索引獲得（log（N）/ N取決於樹的深度與N）。
我讀過，繩索的成功被證明是c中的混合包，因爲性能受到線程安全代碼的傷害。然而，這些問題在不可變的Haskell中應該不重要。事實上，在我看來，正因爲如此，Haskell和繩索纔是理想的選擇。

同樣，像我以前類似的問題，我更感興趣的是結構，而不是當前的情況（庫的使用，如何硬代碼等）的抽象特質。如果你明天重寫了Haskell庫，你會用Data.Rope替代Data.Text嗎？

2013-12-20 jamshidh

「包裝數組的手指樹」似乎是一個很好的代表選擇，但我擔心會有不斷的開銷。一些積極的流融合和一些其他優化短字符串的努力可能會解決這個問題，但Data.Rope缺乏這些功能。現在Data.Rope並不是Data.Text replacmenet。

2013-12-21 00:59:08

但是，這些評論都是關於實現......我很好奇理想的文本與理想的繩索。作爲一個社區我們應該努力的是什麼，偉大的繩索和偉大的文本，還是偉大的繩索？ – jamshidh

字符串與字符串的字符串絕對不是*實現細節。 – Venge

@ Kata-沒有人聲稱它是....我在說這個答案是關於當前圖書館的狀態，我對獨立於圖書館的概念感興趣。 – jamshidh

很久很久以前，當我試圖使用繩索，筆者告訴我這是不是真的有用然而，這只是一個實驗。 Hackage的一個問題是難以瞭解哪些軟件包/版本確實可以投入生產。

是否將Unicode作爲Data.Text與Unicode兼容？

2013-12-28 23:03:48 misterbee

回答