列表推导是否是Haskell的主要部分？

Question

在购买书籍Real World Haskell之前，我查看了网络上的各种Haskell资源。在其他方面非常出色，它似乎没有包含我在所看到的各个网站中提到的列表推导的任何内容。这可能只是因为出于某种原因它们在编写良好的Haskell中通常未被使用，或者它是否更复杂？例如，奇怪的语法可能只是我尚未见过的运算符的一些合并。

Answer 1

Chapter 12中简要提到了列表推导。

我发现自己使用map和filter的组合比Haskell中的列表推导更频繁，但在Python中我会更频繁地使用列表理解。所以我认为它的一部分是个人风格。

一旦您了解了如何使用列表理解的每个部分，您还可以在列表理解方面学到更多内容吗？您有输入，条件/警卫以及返回列表的功能应用程序。我并没有真正看到书中需要大量关于列表理解的部分。

Answer 2

Haskell的定义是拥有一小组核心语言功能，并由一组丰富的语法选项所包围。列表理解是一种选择，但它们并没有提供RWH花费整本书构建直觉的monad糖也没有提供。在很多情况下，Haskell为同一个东西提供了两种语法，let to where，case和combinator面向编程风格，以及列表推导和monad sugar。

列表理解最初是作为monad理解实现的，这一事实在“98年的伟大单形化革命”（又名Haskell '98）中发生了变化。实际上，.NET语言中LINQ的设计源于旧的monad理解设计。列表推导可能比它们更加通用，但是故意削弱它们以使它们更易于理解错误消息。

鉴于纸张数量有限，你必须选择要强调的材料，RWH避免在大多数情况下讨论它们，这样你就不会陷入将列表视为特殊的陷阱。

也就是说，在第12章中对它们进行了简要的提及。到那时，已经为潜在的概念建立了足够的直觉，认为它们并不是真正的危险。

最后，这本书的名字是Real World Haskell。它希望教你良好的现实世界编程技巧。许多Haskellers（并非所有）都避免了列表理解，因为符号不能很好地扩展，并且因为最终，你可能想要回来并改进monad变换器或其他东西，并且最终会重写整个monadic中的理解代码。风格无论如何。

[更新：现在GHC已经重新获得monad comprehensions这个异议并不像以前那么强烈。你可以从中获得一些有趣的新功能。]

Answer 3

列表理解主要出现在小型列表处理示例中，其中许多都是为了在口味方面具有明显的数学性质。当您开始涉及 Real World Haskell 中涵盖的较大应用程序时，列表处理按比例占代码的一小部分。如上所述，使用map，filter，fold，zip等通常也很方便，因为它使用列表推导。

所以

• 在现实世界的Haskell程序中，只有一小部分代码处理列表。

• 使用列表解析编写时，只有一小部分列表处理Haskell代码能够出色地显示出来。

我写的几乎所有列表推导结果都产生了对的列表。但是，我不确定是否应该阅读任何内容。

Answer 4

列表推导是绑定的语法糖（如monad的绑定）列表。

另一种语法糖就是记号。 Imho它更好，最重要的是它适用于所有monad。

如果列表推导不存在，我相信会少一点学习，没有任何东西丢失（你可以使用do-notation）。

赞成列表推导的论据是，它会使用户更清楚它是一个列表。 Imho类型签名对此更有效。

Answer 5

我在RWH中看到了列表理解的three mentions。