“列表理解”可以被视为“功能编程”吗?

时间:2014-05-28 10:00:14

标签: scala functional-programming list-comprehension

Scala代码:

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

我们可以将这种“列表理解”代码视为“函数式编程”风格吗?由于它们将转换为mapflatMap函数?

3 个答案:

答案 0 :(得分:2)

是的,它绝对是一种功能性技术,特别是假设所有这些成员都是字段或纯函数。它只是0或更多flatMap s的句法糖,然后是1 mapif条款被翻译为withFilter)。

最后没有yield,它更像是命令式for,转换为1个或更多foreach个; foreach通常用于执行副作用的声明。

This article更详细地描述了语法,this excellent answer更深入地讨论了一些monadic理论,this article明确地描述了实际的规则转换。

答案 1 :(得分:0)

列表推导构造经常在函数式编程语言中找到,但它并不是函数式编程的独特之处。如果您考虑到这一点,Python,PHP(从5.5版本)和下一版本的Javascript(ES6)也有类似的结构,但这并不代表它们是有用的。

在scala的情况下,你的例子转换为map和flatMap应用程序是正确的,但这并不足以说它是功能性的恕我直言。考虑一下这个案例:

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

这仍然是一种理解,但它实际上是作为任何命令式语言进行副作用(这个循环实际上转换为foreach调用)。

我认为,底线是功能编程并不是关于构造,因为它是关于风格的:对于FP风格的一段代码来说真正重要的是无副作用(或者,在许多情况下,说实话,当副作用发生时)。

如果你想要你甚至可以在Java 7中使用FP:使用匿名类作为闭包,将所有内容标记为final,避免任何可变状态并将副作用隔离到特殊结构中并完成。它会非常冗长,可能很难看,因为这种语言并不支持那种有助于在实践中使这种风格变得更好的抽象,但它仍然是功能性的。

答案 2 :(得分:0)

  

我们可以考虑这样的&#34;列表理解&#34;代码为&#34;函数式编程&#34;样式?

使用命令式/生成器语法的Monadic列表推导是一种相对较新的句法和语义创新。

原始列表推导(例如NPLMiranda)在set comprehensions上建模,并且显然是一个声明性构造,尽管它被转换为嵌套函数。

Haskell的列表推导以类似的方式起作用。

如果我们认为monad是一个功能构造,那么Monadic理解(编译成monadic guard和binds)肯定会被认为是有用的。

相关问题