Qual è la motivazione per l'assegnazione di Scala che valuta a Unità piuttosto che il valore assegnato?

Qual è la motivazione per l'assegnazione di Scala che valuta a Unità piuttosto che il valore assegnato?

Uno schema comune nella programmazione I / O è fare cose come questa:

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

Ma questo non è possibile in Scala perché ...

bytesRead = in.read(buffer)

.. restituisce Unit, non il nuovo valore di bytesRead.

Sembra una cosa interessante da lasciare fuori da un linguaggio funzionale. Mi chiedo perché è stato fatto così?

Ho sostenuto che le assegnazioni restituissero il valore assegnato anziché l'unità. Martin e io siamo andati avanti e indietro su questo argomento, ma il suo argomento era che mettere un valore in pila solo per estrarlo il 95% delle volte era uno spreco di byte-code e aveva un impatto negativo sulle prestazioni.

Non sono a conoscenza di informazioni privilegiate sui motivi reali, ma il mio sospetto è molto semplice. Scala rende i cicli con effetti collaterali scomodi da usare in modo che i programmatori preferiscano naturalmente le comprensioni.

Lo fa in molti modi. Ad esempio, non hai un forciclo in cui dichiari e muti una variabile. Non puoi (facilmente) mutare lo stato su un whileloop nello stesso momento in cui provi la condizione, il che significa che spesso devi ripetere la mutazione appena prima e alla fine di essa. Le variabili dichiarate all'interno di un whileblocco non sono visibili dalla whilecondizione di test, il che rendedo { ... } while (...) molto meno utile. E così via.

Soluzione:

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

Per qualunque cosa valga.

Come spiegazione alternativa, forse Martin Odersky ha dovuto affrontare alcuni bug molto brutti derivanti da tale utilizzo e ha deciso di metterlo fuori legge dalla sua lingua.

MODIFICARE

David Pollack ha risposto con alcuni fatti concreti, che sono chiaramente confermati dal fatto che concreti lo stesso Martin Odersky ha commentato la sua risposta, dando credito all'argomento delle questioni relative alle prestazioni avanzato da Pollack.

Ciò è accaduto perché Scala aveva un sistema di tipi più "formalmente corretto". Formalmente, l'assegnazione è un'affermazione puramente con effetti collaterali e quindi dovrebbe tornare Unit. Questo ha delle belle conseguenze; per esempio:

class MyBean {
  private var internalState: String = _

  def state = internalState

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

Il state_=metodo restituisce Unit(come ci si aspetterebbe da un setter) proprio perché l'assegnazione ritorna Unit.

Sono d'accordo sul fatto che per i modelli in stile C come la copia di un flusso o simili, questa particolare decisione di progettazione può essere un po 'problematica. Tuttavia, in realtà è relativamente non problematico in generale e contribuisce davvero alla coerenza complessiva del sistema di tipi.

Forse ciò è dovuto al principio di separazione tra query e comandi ?

CQS tende ad essere popolare all'intersezione di OO e stili di programmazione funzionale, poiché crea un'ovvia distinzione tra metodi oggetto che hanno o non hanno effetti collaterali (cioè che alterano l'oggetto). L'applicazione di CQS alle assegnazioni di variabili sta andando oltre il solito, ma vale la stessa idea.

Una breve illustrazione del perché CQS è utile: si consideri un linguaggio F / OO ipotetico ibrido con una Listclasse che ha metodi Sort, Append, First, e Length. In imperativo stile OO, si potrebbe voler scrivere una funzione come questa:

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()

Considerando che in uno stile più funzionale, è più probabile scrivere qualcosa del genere:

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()

Questi sembrano tentare di fare la stessa cosa, ma ovviamente uno dei due non è corretto e, senza saperne di più sul comportamento dei metodi, non possiamo dire quale.

Usando CQS, tuttavia, insisteremmo sul fatto che se Appende Sortalteriamo l'elenco, devono restituire il tipo di unità, impedendoci così di creare bug usando la seconda forma quando non dovremmo. La presenza di effetti collaterali diventa quindi implicita anche nella firma del metodo.

Immagino che questo sia per mantenere il programma / il linguaggio privo di effetti collaterali.

Quello che descrivi è l'uso intenzionale di un effetto collaterale che nel caso generale è considerato una cosa negativa.

Non è lo stile migliore utilizzare un compito come espressione booleana. Esegui due cose contemporaneamente, il che porta spesso a errori. E l'uso accidentale di "=" invece di "==" è evitato con la restrizione di Scalas.

A proposito: trovo il trucco iniziale stupido, anche in Java. Perché non qualcosa di simile?

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

Certo, l'assegnazione appare due volte, ma almeno bytesRead rientra nell'ambito a cui appartiene, e non sto giocando con divertenti trucchi di assegnazione ...

Puoi avere una soluzione alternativa per questo, purché tu abbia un tipo di riferimento per l'indirizzamento indiretto. In un'implementazione ingenua, puoi usare quanto segue per i tipi arbitrari.

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

Quindi, sotto il vincolo che dovrai utilizzare ref.valueper accedere al riferimento in seguito, puoi scrivere il tuo whilepredicato come

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

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

e puoi fare il controllo bytesReadin un modo più implicito senza doverlo digitare.