Data.Text与字符串

尽管Haskell社区的普遍观点似乎是总是使用Text代替总是更好String，但是大多数可维护库的API仍然是面向的这一事实使String我感到困惑。另一方面，有一些值得注意的项目，这些项目将全部视为String错误，并且提供了Prelude-String面向功能的所有实例都替换为Text-counterparts的实例。

因此，String除了向后兼容和标准的Prelude兼容以及“切换机制”之外，人们是否有理由继续编写面向对象的API？与之Text相比，是否还有其他缺点String？

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

我无条件的猜测是，大多数库作者都不想添加比必要更多的依赖项。由于字符串实际上是每个Haskell发行版的一部分（它是语言标准的一部分！），如果您使用字符串并且不要求您的用户从黑名单中整理出Text发行版，那么采用起来就容易得多。

这是您必须忍受的那些“设计错误”之一，除非您可以说服大多数社区过夜。只要看看使Applicative成为Monad的超类花了多长时间（一个相对较小但急切需要的更改），并想象用Text替换所有String东西将花费多长时间。

要回答您的更具体的问题：除非您通过使用Text获得明显的性能优势，否则我会选择String。错误消息通常是很小的一次性事件，因此使用String并不是什么大问题。

另一方面，如果您是那种避免实用主义追求理想主义的思想纯粹主义者，那么请选择文本。

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

如果您的API旨在处理大量面向字符的数据和/或各种编码，则您的API应该使用Text。

如果您的API主要用于处理小的一次性字符串，则可以使用内置的String类型。

对大量文本使用字符串将使使用您的API的应用程序消耗大量内存。将其与外部编码一起使用可能会严重复杂化用法，具体取决于您API的工作方式。

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

在小型项目中至少有三个原因使用[Char]。

1. [Char] 不依赖任何奥秘的人员，例如外来指针，原始内存，原始数组等，它们在不同平台上的工作方式可能不同，甚至完全不可用

2. [Char]是Haskell中的lingua franka。至少有三个“高效率”的方式在Haskell处理Unicode数据：utf8-bytestring，Data.Text.Text并且Data.Vector.Unboxed.Vector Char，每个都需要处理额外的软件包。

3. 通过使用[Char]一个命令可以访问[]monad的所有功能，包括许多特定功能（替代字符串程序包确实会尝试提供帮助），但仍然可以

就个人而言，我认为基于utf16的Data.Text问题是haskell社区中最令人质疑的问题之一，因为utf16结合了utf8和utf32编码的缺陷，却没有任何好处。

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

例如，“ cons”对于字符串是O（1），对于文本是O（n）。字符串的附加值为O（n），严格文本的附加值为O（n + m）。同样

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

与严格的文本相比，字符串的空间使用效率更高。

与效率无关的其他问题是模式匹配（透明代码）和延迟（在字符串中每个字符可预测，在某种程度上取决于延迟文本中的实现）。

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

我认为String保留的唯一技术原因不是。而且我可以看到几个解决方案。

总的来说，我首先认为在Text / String案例中只有一个最佳解决方案：

• 弦乐表演很差，每个人都同意

• 文字不难使用。字符串上常用的所有功能都可以在文本上使用，另外一些在字符串上下文中有用的功能（替换，填充，编码）

• 除非所有基本函数都变为多态的，否则具有两个解决方案会产生不必要的复杂性。证明：关于自动转换有一些疑问。所以这是一个问题。

因此，一种解决方案不如两种解决方案复杂，而String的缺点将使其最终消失。越早越好！