Data.Text vs String

Question

虽然Haskell社区的一般意见似乎总是更好地使用Text而不是String,大多数维护的库的API仍然是面向我的事实String混淆了我.另一方面,有一些值得注意的项目,它们String完全被视为一个错误,并提供了Prelude所有String面向函数的实例,这些函数被它们的Text-counterparts 取代.

那么String除了向后兼容的标准Prelude兼容性和"交换制作intertia"之外,人们还有任何理由继续使用面向编写的API吗？与之Text相比,是否还有其他缺点String？

特别是,我对此感兴趣,因为我正在设计一个库并试图决定使用哪种类型来表达错误消息.

Answer 1

我的不合格的猜测是,大多数库编写者不希望添加超过必要的依赖项.由于字符串是字面上每个Haskell发行版的一部分(它是语言标准的一部分!),如果使用字符串并且不要求用户从hackage中整理文本发行版,则更容易被采用.

这是你必须忍受的那些"设计错误"之一,除非你能说服大多数社区过夜.只要看看让Applicative成为Monad的超类 - 已经花了多长时间 - 一个相对较小但很想要的变化 - 并想象用Text替换所有String的东西需要多长时间.

要回答您更具体的问题:我会使用String,除非您通过使用Text获得明显的性能优势.错误消息通常是相当小的一次性事情,因此使用String不应该是一个大问题.

另一方面,如果你是那种回避实用主义理想主义的意识形态纯粹主义者,那么请选择文本.

*我把设计错误放在吓唬引号中,因为作为chars列表的字符串是一个简洁的属性,使得它们易于推理并与其他现有的列表操作函数集成.

Answer 2

如果您的API的目标是处理大量面向字符的数据和/或各种编码,那么您的API应该使用Text.

如果你的API主要用于处理小的一次性字符串,那么使用内置的String类型应该没问题.

对大量文本使用String将使使用API​​的应用程序消耗更多内存.使用外部编码可能会严重影响使用情况,具体取决于API的工作方式.

字符串非常昂贵(至少5N个字,其中N是字符串中Char的数量).一个字与处理器体系结构的位数相同(例如32位或64位):http: //blog.johantibell.com/2011/06/memory-footprints-of-some-common-data.html

Answer 3

在小项目中使用[Char]至少有三个理由.

1. [Char] 不依赖于任何神秘的工作人员,如外国指针,原始内存,原始数组等,可能在不同的平台上以不同的方式工作,甚至完全不可用

2. [Char]是haskell的通用语.至少有三个"高效率"的方式在Haskell处理Unicode数据:utf8-bytestring,Data.Text.Text并且Data.Vector.Unboxed.Vector Char,每个都需要处理额外的软件包.

3. 通过使用[Char]一个获得访问[]monad的所有功能,包括许多特定的功能(替代字符串包确实试图帮助它,但仍然)

就个人而言,我认为基于utf16的Data.Text是haskell社区最值得怀疑的问题之一,因为utf16结合了utf8和utf32编码的缺陷,同时没有任何好处.

Answer 4

我想知道 Data.Text 是否总是比 Data.String 更有效率？？？

例如，“缺点”是字符串的 O(1) 和文本的 O(n)。追加对于字符串是 O(n)，对于严格文本是 O(n+m)。同样地，

    let foo = "foo" ++ bigchunk
        bar = "bar" ++ bigchunk

字符串比严格文本更节省空间。

其他与效率无关的问题是模式匹配（清晰的代码）和惰性（可预测字符串中的每个字符，惰性文本中以某种方式依赖于实现）。

文本显然适用于静态字符序列和就地修改。对于其他形式的结构编辑，Data.String 可能具有优势。