在购买《Real World Haskell》这本书之前，我查看了网络上的各种 Haskell 资源。在其他方面非常出色，它似乎不包含我在我查看的各个网站中提到的列表推导的任何内容。这可能只是因为出于某种原因它们通常在编写良好的 Haskell 中未被使用，还是因为它更复杂？例如，看起来奇怪的语法可能只是我还没有见过的运算符的一些合并。
【问题讨论】：
标签： list list-comprehension haskell
Chapter 12 中简要提到了列表推导。
我发现自己使用 map 和 filter 的组合比 Haskell 中的列表推导更频繁，但在 Python 中我会更频繁地使用列表推导。所以我认为部分原因是个人风格。
一旦您了解了如何使用列表推导式的各个部分，您还有哪些关于列表推导式的学习内容？你有你的输入，你的条件/保护，以及返回列表的函数应用程序。我真的认为没有必要在一本书中写一大段关于列表推导的内容。
【讨论】：
MonadPlus 而不仅仅是[a] ... ;)
列表推导是绑定（如在 monad 的绑定中）列表的语法糖。
另一个语法糖是do-notation。恕我直言，它更好，最大的优点是它适用于所有单子。
如果不存在列表推导式，我相信要学习的东西会少一点，而且不会丢失任何东西（您可以改用 do-notation）。
支持列表推导的论点是它会让用户更清楚它是一个列表。恕我直言，类型签名会更好。
【讨论】：
Haskell 的定义是拥有一小组核心语言功能，周围是一组丰富的句法选择。列表推导是一种选择，但它们没有提供任何 RWH 花费整本书建立直觉的单子糖也没有提供。在很多情况下，Haskell 为同一事物提供两种语法，let 与 where，面向大小写和组合子的编程风格，以及列表推导和 monad 糖。
列表推导最初是作为 monad 推导实现的，这一事实在“98 年的大单态化革命”（又名 Haskell '98）中发生了变化。事实上，.NET 语言中的 LINQ 设计很大程度上源于较旧的 monad 理解设计。列表推导式可能比它们更通用，但被故意削弱以使它们产生更容易理解的错误消息。
鉴于纸张数量有限，您必须选择要强调的材料，而 RWH 大部分时间都避免谈论它们，这样您就不会陷入将列表视为特殊事物的陷阱。
也就是说，在第 12 章中简要提到了它们。到那时，已经为基本概念建立了足够的直觉，认为它们并不是真正的危险。
最后，这本书的名字是 Real World Haskell。它想教你良好的现实世界编程技术。许多Haskellers（不是全部）避免列表推导，因为符号不能很好地扩展，并且因为最终，您可能想要回来并改装一个monad转换器或其他东西，并且最终会用monadic重写整个理解代码无论如何都要风格。
[更新：现在 GHC 重新获得了monad comprehensions 这个反对意见不像以前那么强烈了。您可以从中获得一些有趣的新功能。]
【讨论】：
我在 RWH 中看到 three mentions 的列表理解。
【讨论】：
列表推导式主要出现在小型列表处理示例中，其中许多旨在明显具有数学风格。当您开始使用诸如 Real World Haskell 中介绍的大型应用程序时，列表处理在比例上只占代码的一小部分。如前所述，使用map、filter、fold、zip 等通常与使用列表推导式一样方便。
所以
在现实世界的 Haskell 程序中，只有一小部分代码处理列表。
只有一小部分处理列表的 Haskell 代码在使用列表推导式编写时表现得更好。
我写的几乎所有列表推导式都生成了对列表。但是，我不确定是否应该对此进行解读。
【讨论】：