为什么使用foldLeft而不是程序版本？

Question

因此，在阅读这个问题时，有人指出，而不是程序代码：

def expand(exp: String, replacements: Traversable[(String, String)]): String = {
  var result = exp
  for ((oldS, newS) <- replacements)
    result = result.replace(oldS, newS)
  result
}

您可以编写以下功能代码：

def expand(exp: String, replacements: Traversable[(String, String)]): String = {
  replacements.foldLeft(exp){
    case (result, (oldS, newS)) => result.replace(oldS, newS)
  }
}

我几乎肯定会编写第一个版本，因为熟悉过程或函数风格的程序员可以轻松阅读和理解它，而只有熟悉函数风格的程序员才能轻松阅读和理解第二个版本。

但暂时把可读性放在一边，有什么东西可以让 foldLeft 成为比程序版本更好的选择吗？我可能认为它会更有效，但事实证明 foldLeft的实现实际上就是上面的程序代码。那么这只是一种风格选择，还是有充分的理由使用一个版本或另一个版本？

编辑：需要明确的是，我不是在问其他函数，只是在问foldLeft。我对使用 foreach、map、filter 等非常满意，它们都很好地映射到 for 推导式上。

答案：这里确实有两个很好的答案（由 delnan 和 Dave Griffith），尽管我只能接受一个：

• 使用 foldLeft 因为还有其他优化，例如使用while 循环比 for 循环更快。
• 如果将其添加到常规集合中，请使用折叠，因为这将使向并行集合的转换变得微不足道。

Answer 1

它更短、更清晰 - 是的，您需要知道折叠是什么才能理解它，但是当您使用 50% 函数式语言进行编程时，您无论如何都应该了解这些基本构建块。折叠正是过程代码所做的事情（重复应用操作），但它被赋予了名称并进行了概括。虽然你正在重新发明的只是一个小轮子，但它仍然是一个轮子的重新发明。

如果 FoldLeft 的实现应该获得一些特殊的好处 - 例如额外的优化 - 您可以免费获得它，而无需更新无数的方法。

Answer 2

除了对可变变量（甚至可变局部变量）的厌恶之外，在这种情况下使用折叠的基本原因是清晰，偶尔简洁。折叠版本的大部分冗长之处是因为您必须使用带有解构绑定的显式函数定义。如果列表中的每个元素在折叠操作中仅使用一次（常见情况），则可以简化为使用简短形式。因此，数字集合之和的经典定义

collection.foldLeft(0)(_+_) 

比任何等效的命令式构造要简单得多且短得多。

使用函数式收集操作的另一个元原因（尽管在本例中不直接适用）是为了在性能需要时转向使用并行收集操作。折叠不能并行化，但折叠操作通常可以转化为交换关联归约操作，并且这些操作可以并行化。使用 Scala 2.9，利用多个处理核心将某些内容从非并行功能更改为并行功能有时就像将 .par 拖放到要执行并行操作的集合上一样简单。

Answer 3

我在这里还没有看到提到的一个词是声明性：

声明式编程通常被定义为非命令式的任何编程风格。存在许多其他常见定义，试图为该术语提供一个定义，而不是简单地将其与命令式编程进行对比。例如：

• 一个程序，描述应该执行什么计算以及而不是如何计算
• 任何没有副作用（或更具体地说，引用透明）的编程语言
• 一种与数学逻辑具有明确对应关系的语言。

这些定义实质上重叠。

高阶函数 (HOF) 是声明性的关键推动者，因为我们只指定内容（例如“使用这个值集合，将每个值乘以 2，对结果求和”），而不是指定如何（例如初始化累加器、使用 for 循环进行迭代、从集合中提取值、添加到累加器...）。

比较以下内容：

// Sugar-free Scala (Still better than Java<5)
def sumDoubled1(xs: List[Int]) = {
  var sum = 0                     // Initialized correctly?
  for (i <- 0 until xs.size) {    // Fenceposts?
    sum = sum + (xs(i) * 2)       // Correct value being extracted? 
                                  // Value extraction and +/* smashed together
  }       
  sum                             // Correct value returned?
}

// Iteration sugar (similar to Java 5)
def sumDoubled2(xs: List[Int]) = {
  var sum = 0
  for (x <- xs)          // We don't need to worry about fenceposts or 
    sum = sum + (x * 2)  // value extraction anymore; that's progress
  sum                               
}

// Verbose Scala
def sumDoubled3(xs: List[Int]) = xs.map((x: Int) => x*2). // the doubling
                                    reduceLeft((x: Int, y: Int) => x+y) // the addition

// Idiomatic Scala
def sumDoubled4(xs: List[Int]) = xs.map(_*2).reduceLeft(_+_)
//                                       ^ the doubling  ^
//                                                       \ the addition

请注意，我们的第一个示例 sumDoubled1 已经比（大多数人认为优于）C/C++/Java<5 for 循环更具声明性，因为我们不必对迭代状态和终止逻辑，但我们仍然容易受到差一错误的影响。

接下来，在sumDoubled2中，我们基本上处于Java>=5的水平。仍然有一些事情可能会出错，但我们已经非常擅长阅读这种代码形状，因此不太可能出现错误。 但是，不要忘记，在玩具示例中微不足道的模式在扩展到生产代码时并不总是那么可读！

使用用于教学目的的去糖化的 sumDoubled3 和惯用的 Scala 版本 sumDoubled4，迭代、初始化、值提取和返回值选择都消失了。

当然，学习阅读功能版本需要时间，但我们已经彻底排除了犯错误的选择。 “业务逻辑”被明确标记，并且管道是从其他人正在阅读的同一个菜单中选择的。

Answer 4

值得指出的是，还有另一种调用 foldLeft 的方法，它具有以下优点：

• 在标识符中使用（几乎）任何 Unicode 符号
• 的功能 如果方法名称以冒号 < 结尾，则该功能code>:，并且被称为中缀，然后目标和参数被切换

对我来说这个版本更清晰，因为我可以看到我将 expr 值折叠到中 replacements 集合

def expand(expr: String, replacements: Traversable[(String, String)]): String = {
  (expr /: replacements) { case (r, (o, n)) => r.replace(o, n) }
}