“列表理解”可以被视为“函数式编程”吗？

Question

Scala code：

for {
   user <- users
   name <- user.names
   letter <- name.letters
} yield letter

我们可以将这种“列表理解”代码视为“函数式编程”风格吗？因为它们将被转换为map和flatMap？

Answer 1

我们可以将这种“列表理解”代码视为“函数式编程”风格吗？

具有命令式/生成器语法的一元列表推导是一种相对较新的语法和语义创新。

最初的列表理解(例如NPL或Miranda)是在集合理解的基础上建模的，并且显然是声明性的构造，尽管它被翻译成嵌套函数。

Haskell的列表理解功能类似。

如果我们认为单子是一个功能结构，那么单子理解（编译成单子守卫和绑定）肯定应该被认为是功能的。

Answer 2

匿名用户

列表理解结构经常出现在函数式编程语言中，但它与函数式编程没有区别。如果你也这样想的话，Python、PHP（5.5版）和下一个Javascript版本（ES6）也有类似的结构，但这并不意味着它们是功能性的。

在scala的例子中，你的例子可以转换成map和flatMap应用程序，但是这还不足以说明它是功能性的。考虑这种情况:

for {
  i <- 1 until 10
} println(i)

这仍然是一个需要理解的问题，但是它实际上和任何命令式语言一样有副作用(这个循环实际上转化为< code>foreach调用)。

在我看来，归根结底，函数式编程与结构无关，而与风格有关：一段代码采用FP风格，真正重要的是没有副作用（或者，在许多情况下，诚实地说，副作用何时发生）。

如果你愿意，你甚至可以在Java 7中实现FP:使用匿名类作为闭包，将所有东西都标记为final，避免任何可变状态，并将副作用隔离到特殊的构造中，这样就完成了。它会非常冗长，而且可能很难看，因为这种语言不支持有助于使这种风格在实践中变得更好的抽象，但它仍然是函数式的。

Answer 3

是的，这绝对是一种函数式技术，特别是假设所有这些成员都是字段或纯函数。它只是0个或更多 flatMap的语法糖，后跟 1 个 map（if 子句转换为 withFilter）。

如果末尾没有rent，它的行为更像的命令式，转换为1个或多个foreachs；Foreach通常用于执行语句以消除其副作用。

本文更详细地描述了语法，这个优秀的答案用一些一元理论更深入地讨论了它，本文明确地描述了实际的规则翻译。