为什么Haskell的默认字符串实现是字符链表？

Question

Haskell的默认String实现在速度和内存方面都不高效这一事实是众所周知的。 据我所知， [] lists一般在Haskell中实现为单链表和大多数小/简单数据类型（例如Int ），它似乎不是一个好主意，但对于String它似乎总计矫枉过正。 关于此事的一些意见包括：

真实世界哈斯克尔

在像这样的简单基准测试中，即使用Python等解释语言编写的程序也可以胜过使用String一个数量级的Haskell代码。

Haskell中的高效字符串实现

由于String只是[Char]，这是Char的链接列表，这意味着字符串的引用局部性较差，并且再次意味着字符串在内存中相当大，至少它是N *（21bits + Mbits）其中N是字符串的长度，M是指针的大小（...）。 字符串不太可能被编译器优化为循环等。

我知道Haskell有几种不同风格的ByteString （和Array s），并且它们可以很好地完成工作，但我希望默认实现是最有效的。

TL; DR：为什么Haskell的默认String实现是单链表，即使它非常低效并且很少用于真实世界的应用程序（除了非常简单的应用程序）？ 有历史原因吗？ 实施起来更容易吗？

Answer 1

为什么Haskell的默认String实现是单链表

因为单链接列表支持：

• 通过模式匹配进行归纳
• 有一些有用的属性，比如Monad，Functor
• 是正确的参数多态
• 自然是懒惰的

所以String作为[Char] （unicode points）意味着符合语言目标的字符串类型（截至1990年），并且基本上是免费的“列表库”。

总之，历史上语言设计者对设计良好的核心数据类型感兴趣，而不是文本处理的现代问题，所以我们有一个优雅，易于理解，易于教授的String类型，这不是一个unicode文本块，并不是一个密集，打包，严格的数据类型。

Answer 2

效率只是衡量抽象的一个轴。 虽然列表对于text-y操作来说效率很低，但是它们很方便，因为有很多列表操作以多态方式实现，当专门用于[Char]时有很多有用的解释，所以你在库实现和用户的大脑。

目前尚不清楚，如果我们目前的经验水平是从头开始设计的，那么同样的决定也是如此; 然而，在经验可用之前，并不总是能够做出完美的决策。

Answer 3

在这一点上，它可能是历史性的：使ByteString这样的东西变得如此高效的优化是最近的 ，而[Char]它们之前都是多年。