为何Monoid的mconcat限定为列表而非更通用的Foldable？

这是个非常好的观察！你提出的这个问题戳中了Haskell标准库演进中的两个关键考量：历史兼容性和特定类型的性能优化，下面具体拆解：

1. 历史包袱：Foldable是后来才加入的 #

Haskell的Monoid类型类早在Haskell 98标准时期就已经存在了，但Foldable（以及配套的Traversable）直到2015年左右的GHC 7.10版本才被正式纳入标准库。

在Foldable出现之前，根本没有“通用可折叠容器”的抽象概念，mconcat自然只能基于最常用的列表类型来定义。等到Foldable普及后，标准库团队也不敢直接修改mconcat的签名——毕竟当时已经有大量旧代码依赖mconcat :: [a] -> a这个类型，贸然改动会导致无数代码编译失败，破坏向后兼容性。

2. 针对列表的专属优化 #

虽然理论上foldr mappend mempty可以适配任何Foldable容器，但对于列表这种使用频率最高的容器，我们可以提供更高效的专门实现。

比如GHC标准库中，列表的mconcat其实并没有直接用foldr，而是做了底层优化：它会避免在每一步拼接时创建不必要的闭包，处理长列表时的性能比通用foldr实现要高不少。如果把mconcat改成通用的Foldable签名，这种针对列表的特殊优化就没办法直接绑定到这个函数上了——要么得放弃优化，要么得额外写一个专门的列表版本，反而增加了开发者的负担。

替代方案：通用版本其实已经存在 #

如果你需要支持任意Foldable容器的“合并Monoid元素”功能，标准库其实已经提供了现成的函数：Data.Foldable里的fold，它的签名就是：

fold :: (Foldable t, Monoid m) => t m -> m

这个函数和你定义的mconcat'完全等价，本质上就是foldMap id，可以完美处理所有可折叠容器的Monoid合并需求。

内容的提问来源于stack exchange，提问作者fphilipe