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