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

Question

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

Answer 1

列表理解在第12章中简要提及.

我发现自己使用地图和过滤器的组合比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的理解,这个异议并不像以前那么强烈.你可以从中获得一些有趣的新功能.]

Answer 3

列表推导主要出现在小型列表处理示例中,其中许多旨在明显地具有数学风格.当您开始涉及Real World Haskell所涵盖的较大应用程序时,列表处理按比例占代码的一小部分.正如指出的,它往往是一样方便使用map,filter,fold,zip,等等,因为它是用一个列表理解.

所以

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

• 使用列表解析编写时,只有一小部分列表处理Haskell代码显得更好.

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

Answer 4

列表推导是用于绑定的语法糖(如在monad的绑定中)列表.

另一种语法糖就是做法.Imho它更好,最重要的是它适用于所有monad.

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

支持列表推导的论据是,它会使用户更清楚它是一个列表.Imho类型签名对此更有效.