Option.fold - 为什么它的第二个参数不是二元运算符？答案

【问题标题】：Option.fold - why is its second argument not a binary operator?Option.fold - 为什么它的第二个参数不是二元运算符？
【发布时间】：2014-10-17 11:16:14
【问题描述】：

我确信这是有充分理由的，但我没有看到。

Fold on（比如）List 返回

在所有元素和z之间应用折叠运算符op的结果

它与 foldLeft 和 foldRight 有明显的关系，它们做同样的事情但具有定义的顺序（因此不需要关联运算符）

Fold Option 返回

如果scala.Option 不为空，则返回将f 应用于此scala.Option 的值的结果。否则，计算表达式 ifEmpty。

ifEmpty 是（位于）z 的列表。 f 是op 的（位置）

对于None（使用我的Option 心理模型作为可能包含或不包含值的“容器”，是一个“空”容器），一切正常，Option.fold 返回零（ifEmpty 的值）。

对于Some(x)，但是，f 不应该有两个参数，z 和 x，因此它与序列上的fold 一致（包括与foldLeft 和@987654350 具有相似的关系@)。

肯定有一个实用的论据反对这一点-在实践中，f 只需将x 作为参数可能更方便。在大多数情况下，如果它也需要z，那将被忽略。但一致性也很重要......

那么有人可以向我解释为什么 Option 上的 fold 仍然是“正确的”fold 吗？

【问题讨论】：

但 Some#fold 确实需要 2 个参数。 github.com/scala/scala/blob/v2.11.3/src/library/scala/…不好意思我没看懂问题
它确实需要两个参数；但参数只是在单独的参数列表中。
我在问为什么第二个参数不是二元运算符。不是为什么 fold 本身需要两个参数 - 正如你所说的那样！
几个月前我写了a blog post关于类似的问题。
fold 函数的结构总是与容器的形状有关。在树上，您必须有 3 个参数：累加器、节点本身的值和子节点值的 Seq。我们知道和喜爱的二元折叠不应该被认为是普遍的。不久前我写了一个答案：stackoverflow.com/questions/24132325/….

【解决方案1】：

为什么会这样？

折叠“通常”采用二元运算符的原因是，“通常”用于可以使用二元运算符（和种子值 z）一一处理的列表。

Fold on an option 实际上是一个带有默认情况的映射函数。如果你看它的定义，它的字面意思是：

if (isEmpty) ifEmpty else f(this.get)

由于您只有一个可能的参数，因此 f 必须是一元运算符。有人可能会争辩说有一个选项折叠，它采用二元运算符并使用 ifEmpty 值作为种子，以防选项被定义，但你的明智种子值和你在选项为空时的明智值可能会有很大不同。

正如有人指出的那样，对于不同的结构，您需要不同的参数（例如树），因为归约的“合理”应用具有不同的结构。

【讨论】：

【解决方案2】：

scala.Option.fold 是一个错误；糟糕的 API 设计。

Option {
  // This is equivalent to:  map f getOrElse ifEmpty.
  def fold[B](ifEmpty: => B)(f: A => B): B = if (isEmpty) ifEmpty else f(this.get)
}

Option.fold 方法可能很方便，但它不是 fold（Either.fold 也是如此）。

TraversableOnce {
  // List, et alia
  def fold[A1 >: A](z: A1)(op: (A1, A1) => A1): A1 = foldLeft(z)(op)
}

标准方法的好处是概念和类型签名是一致的（无需再次查看文档）。

另外，Option.foldLeft 是一致的，并且确实采用二元运算符。

【讨论】：