处理大量文本数据时，建议使用Data.Text，而不是haskells原生字符串。检查，完成。但是正则表达式呢？是否有专门针对Data.Text 的正则表达式库？据我所知，所有正则表达式库都在使用 Haskell 原生字符串，甚至更糟糕的 CString。
【问题讨论】：
来自Data.Text documentation：
使用扩展且非常丰富的函数系列来处理 Unicode 文本（包括规范化、正则表达式、 非标准编码、文本中断和语言环境），请参阅 text-icu 包：http://hackage.haskell.org/package/text-icu
更准确地说是Data.Text.ICU.Regex
【讨论】：
regex-tdfa 在Text.Regex.TDFA.Text 模块中提供基于Text 的接口。它相对于text-icu 包的优势在于它不使用IO monad，因此更易于使用。
【讨论】：
正则表达式生态系统和 Haskell
正则表达式是一种工具，人们从其他语言迁移过来只是希望成为该语言中可用的工具之一。在编译语言中，此功能往往以库的形式出现，例如 PCRE。脚本语言通常在语言中内置了正则表达式，但在底层，解释器使用的是这些相同的库之一。
这是有充分理由的。有限状态自动机相当神秘，实施起来有些乏味，而且很难提高效率。为什么要重新发明轮子？
那么 Haskell 有什么问题呢？好吧，这些众所周知的库都适用于以 NUL 字节结尾的 8 位字数组——在 Haskell 命名法中是 CString。 Haskell 中的常规字符串是Char 的列表。 （字面意思：type String = [Char]）。这会导致两个问题：1) char 是单个 unicode 字符，而不是 8 位字节。 （GHC 在内部将 Char 存储为 UTF16）和 2）列表不是数组。这意味着如果我们想在 Haskell 中执行 Regex，我们要么需要将文本转换为 CStiring 并对外调用 PCRE 之类的东西，要么实现高效的有限状态自动机和regex parser natively。
将 unicode 转换为 ascii 是一项有损且有风险的操作。一些库对他们正在处理的字符串做出一些假设并为您进行转换，其他库让您为他们构建 CString，以便您可以弄清楚当 ☃ 出现在游览文本中时该怎么做。
那么Data.Text 呢？好吧，它至少是一个数组，但在内部它是一个 UTF16 数组。仍然可以转换为 8 位 CString，但效率不高。也有可能使用 unicode 感知正则表达式引擎。 International Components for Unicode (ICU) 有 such a library 并且在 text-icu 包中有一个绑定。 Unicode 的本质意味着这个包的效率不如 PCRE，所以有些人更喜欢仍然使用对后者的绑定。您必须根据您使用正则表达式的目的来决定您的偏好。
【讨论】：