5

これには正当な理由があると確信していますが、私はそれを見ていません。

Foldオン（言う）Listリターン

opすべての要素の間に折り畳み演算子を適用した結果とz

and との明らかな関係がfoldLeftありfoldRightますが、同じことを行いますが、順序が定義されています (したがって、結合演算子は必要ありません)。

FoldOption返品について

が空でない場合、fthisの値に適用した結果を返します。それ以外の場合は、式を評価します。scala.Optionscala.OptionifEmpty

ifEmptyzリスト の (の位置にある)です。fは（の位置に）op

（値を含む場合と含まない場合がある「コンテナ」としてのNone私のメンタルモデルを使用すると、「空の」コンテナです）、問題はなく、ゼロ（の値）を返します。OptionOption.foldifEmpty

Some(x)ただし、 for は 2 つのパラメーターを取るべきではないためf、 on シーケンスzとx一致します (および とfold同様の関係を持つことを含む)。foldLeftfoldRight

これには間違いなく実用的な議論があります -実際にはパラメータとしてf取るだけxの方がおそらく便利です。ほとんどの場合、それもかかっzた場合は無視されます。しかし、一貫性も重要です...

では、なぜfoldon Option がまだ「適切」なのか説明してもらえますfoldか?

4

2 に答える 2

2

なぜそれが必要なのですか？

フォールドが「通常」二項演算子を取る理由は、二項演算子 (およびシード値 z) で 1 つずつ処理できるリストに対して「通常」が使用されるためです。

オプションのフォールドは、事実上、デフォルトのケースを持つマップ関数です。その定義を見ると、文字通り次のようになります。

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

可能な引数は 1 つしかないため、f は単項演算子でなければなりません。オプションが定義されている場合に、二項演算子を取り、ifEmpty 値をシードとして使用するオプション フォールドがあると主張することもできますが、適切なシード値とオプションが空の場合の適切な値は大きく異なる場合があります。

誰かが指摘したように、構造が異なると (ツリーなど)、異なるアリティが必要になります。これは、リダクションの「賢明な」適用には異なる構造があるためです。

于 2014-10-22T15:04:41.360 に答える
0

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 。

于 2014-10-24T20:47:43.270 に答える