割り当てられた値ではなく、ユニットに評価されるScala割り当ての動機は何ですか？

Question 1

I / Oプログラミングの一般的なパターンは、次のようなことです。

while ((bytesRead = in.read(buffer)) != -1) { ...

しかし、これはScalaでは不可能です...

bytesRead = in.read(buffer)

.. bytesReadの新しい値ではなく、Unitを返します。

関数型言語から除外するのは興味深いことのようです。なぜそうなったのかしら？

Question 2

私は、割り当てが単位ではなく割り当てられた値を返すようにすることを提唱しました。マーティンと私はそれを行ったり来たりしましたが、彼の主張は、95％の時間で値をスタックに置くことはバイトコードの無駄であり、パフォーマンスに悪影響を与えるというものでした。

Question 3

私は実際の理由についての内部情報に精通していませんが、私の疑いは非常に単純です。Scalaは、プログラマーが当然のことながら内包表記を好むように、副作用のあるループを使いにくいものにします。

それは多くの方法でこれを行います。たとえばfor、変数を宣言して変更するループはありません。while条件のテストと同時にループの状態を（簡単に）変更することはできません。つまり、多くの場合、変更の直前と終了時に変更を繰り返す必要があります。whileブロック内で宣言された変数は、whileテスト条件からは見えないため、do { ... } while (...)あまり役に立ちません。等々。

回避策：

while ({bytesRead = in.read(buffer); bytesRead != -1}) { ...

それが価値があるものは何でも。

別の説明として、おそらくマーティン・オーダスキーは、そのような使用法に由来するいくつかの非常に醜いバグに直面しなければならず、彼の言語からそれを非合法化することに決めました。

編集

デビッド・ポラックはいくつかの実際の事実で答えましたが、マーティン・オーダスキー自身が彼の答えにコメントし、ポラックが提起したパフォーマンス関連の問題の議論に信憑性を与えているという事実によって明確に裏付けられています。

Question 4

これは、より「正式に正しい」型システムを持つScalaの一部として発生しました。正式に言えば、割り当ては純粋に副作用のあるステートメントであるため、を返す必要がありますUnit。これにはいくつかの良い結果があります。例えば：

class MyBean {
  private var internalState: String = _

  def state = internalState

  def state_=(state: String) = internalState = state
}

state_=メソッドの戻りUnit（セッターのために予想されるように）正確に割り当て返すためUnit。

ストリームのコピーなどのCスタイルのパターンの場合、この特定の設計上の決定は少し面倒になる可能性があることに同意します。ただし、実際には一般的に比較的問題はなく、型システムの全体的な一貫性に大きく貢献します。

Question 5

おそらくこれは、コマンドとクエリの分離によるものです原則によるものですか？

CQSは、副作用のあるオブジェクトメソッドとないオブジェクトメソッド（つまり、オブジェクトを変更するメソッド）を明確に区別するため、OOと関数型プログラミングスタイルの共通部分で人気があります。変数の割り当てにCQSを適用すると、通常よりもさらに進んでいますが、同じ考え方が当てはまります。

短いCQSが有用である理由の説明図：を有する仮想的ハイブリッドF /オブジェクト指向言語を検討Listメソッドを有するクラスはSort、Append、First、およびLength。命令型OOスタイルでは、次のような関数を記述したい場合があります。

func foo(x):
    var list = new List(4, -2, 3, 1)
    list.Append(x)
    list.Sort()
    # list now holds a sorted, five-element list
    var smallest = list.First()
    return smallest + list.Length()

一方、より機能的なスタイルでは、次のように書く可能性が高くなります。

func bar(x):
    var list = new List(4, -2, 3, 1)
    var smallest = list.Append(x).Sort().First()
    # list still holds an unsorted, four-element list
    return smallest + list.Length()

これらは試みているようです同じことをしてが、明らかに2つのうちの一方が正しくなく、メソッドの動作について詳しく知らなければ、どちらかを判断することはできません。

ただし、CQSを使用するAppendとSort、リストを変更する場合はユニットタイプを返す必要があるため、必要のないときに2番目のフォームを使用してバグを作成することはできません。したがって、副作用の存在もメソッドシグネチャに暗黙的に含まれます。

Question 6

これは、プログラム/言語に副作用がないようにするためだと思います。

あなたが説明するのは、一般的に悪いことと考えられている副作用の意図的な使用です。

Question 7

割り当てをブール式として使用するのは最適なスタイルではありません。2つのことを同時に実行すると、エラーが発生することがよくあります。また、Scalasの制限により、「==」の代わりに「=」を誤って使用することは回避されます。

Question 8

ちなみに、Javaでも、最初のwhile-trickはばかげています。なぜこのような何かをしないのですか？

for(int bytesRead = in.read(buffer); bytesRead != -1; bytesRead = in.read(buffer)) {
   //do something 
}

確かに、割り当ては2回表示されますが、少なくともbytesReadはそれが属するスコープ内にあり、面白い割り当てのトリックで遊んでいません...

Question 9

間接参照の参照型がある限り、これを回避することができます。ナイーブな実装では、任意のタイプに以下を使用できます。

case class Ref[T](var value: T) {
  def := (newval: => T)(pred: T => Boolean): Boolean = {
    this.value = newval
    pred(this.value)
  }
}

次に、後でref.value参照にアクセスするために使用する必要がある制約の下で、while述語を次のように記述できます。

val bytesRead = Ref(0) // maybe there is a way to get rid of this line

while ((bytesRead := in.read(buffer)) (_ != -1)) { // ...
  println(bytesRead.value)
}

またbytesRead、入力しなくても、より暗黙的な方法でチェックを行うことができます。