2013-12-20 46 views
14

我一直在寻找绳索作为Data.Text的替代品,而且我喜欢我所看到的如此之多以致于我现在被迫问这个问题....是否有任何情况下Data.Text将是更好的选择?Data.Text与绳索

下面是导致我这个(纠正我,如果我错了,对任何这些)点 -

  1. 单叶节点绳子内部(几乎)同样的事情作为Data.Text对象。单节点绳索与文本的开销很小,只是用于区分分支或叶子的单个位标志。如果你真的想要Data.Text,只需使用非分离的绳索。

  2. 复杂性在绳索插入/删除(log(N)vs N)中通过相等或更好,通过索引获得(log(N)/ N取决于树的深度与N)。

  3. 我读过,绳索的成功被证明是c中的混合包,因为性能受到线程安全代码的伤害。然而,这些问题在不可变的Haskell中应该不重要。事实上,在我看来,正因为如此,Haskell和绳索才是理想的选择。

同样,像我以前类似的问题,我更感兴趣的是结构,而不是当前的情况(库的使用,如何硬代码等)的抽象特质。如果你明天重写了Haskell库,你会用Data.Rope替代Data.Text吗?

回答

8

“包装数组的手指树”似乎是一个很好的代表选择,但我担心会有不断的开销。一些积极的流融合和一些其他优化短字符串的努力可能会解决这个问题,但Data.Rope缺乏这些功能。现在Data.Rope并不是Data.Text replacmenet。

  1. 它主要实现字符串而不是charachters字符串 - 它取代byteString而不是文本。 Unicode支持很重要。
  2. 尽管爱德华很惊人,绳子还没有成熟。它在一年内没有任何贡献,并且很少使用。
  3. Data.Text背后都有一个庞大的工程计划,是高度优化,而且是众所周知的,有据可查的
+1

但是,这些评论都是关于实现......我很好奇理想的文本与理想的绳索。作为一个社区我们应该努力的是什么,伟大的绳索和伟大的文本,还是伟大的绳索? – jamshidh

+4

字符串与字符串的字符串绝对不是*实现细节。 – Venge

+0

@ Kata-没有人声称它是....我在说这个答案是关于当前图书馆的状态,我对独立于图书馆的概念感兴趣。 – jamshidh

0

很久很久以前,当我试图使用绳索,笔者告诉我这是不是真的有用然而,这只是一个实验。 Hackage的一个问题是难以了解哪些软件包/版本确实可以投入生产。

是否将Unicode作为Data.Text与Unicode兼容?