Perché tante lingue vengono passate per valore?

Anche i linguaggi in cui hai una manipolazione esplicita del puntatore come C viene sempre passato per valore ( puoi passarli per riferimento ma non è il comportamento predefinito).

Qual è il vantaggio di questo, perché tante lingue sono passate per valori e perché altre sono passate per riferimento ? (Capisco che Haskell è passato per riferimento anche se non ne sono sicuro).

Il passaggio per valore è spesso più sicuro del passaggio per riferimento, poiché non è possibile modificare accidentalmente i parametri nel metodo / funzione. Questo rende il linguaggio più semplice da usare, poiché non devi preoccuparti delle variabili che dai a una funzione. Sai che non saranno cambiati, e questo è spesso quello che ti aspetti .

Tuttavia, se si desidera modificare i parametri, è necessario disporre di alcune operazioni esplicite per chiarire questo aspetto (passare un puntatore). Ciò costringerà tutti i chiamanti a rendere la chiamata in modo leggermente diverso ( &variable, in C) e ciò rende esplicito che il parametro variabile può essere modificato.

Quindi ora puoi presumere che una funzione non cambierà il tuo parametro variabile, a meno che non sia esplicitamente contrassegnato per farlo (richiedendo di passare un puntatore). Questa è una soluzione più sicura e più pulita dell'alternativa: supponiamo che tutto possa cambiare i tuoi parametri, a meno che non lo affermino specificamente.

Call-by-value e call-by-reference sono tecniche di implementazione che sono state confuse molto tempo fa con le modalità di passaggio dei parametri.

All'inizio c'era FORTRAN. FORTRAN aveva solo una chiamata per riferimento, poiché le subroutine dovevano essere in grado di modificare i loro parametri e i cicli di calcolo erano troppo costosi per consentire più modalità di passaggio dei parametri, inoltre non si sapeva abbastanza sulla programmazione quando FORTRAN fu definito per la prima volta.

ALGOL ha inventato il call-by-name e il call-by-value. La chiamata per valore era per cose che non dovevano essere modificate (parametri di input). La chiamata per nome era per i parametri di output. Il call-by-name si rivelò essere un grande idiota e ALGOL 68 lo lasciò cadere.

PASCAL ha fornito call-by-value e call-by-reference. Non ha fornito al programmatore alcun modo per dire al compilatore che stava passando un oggetto di grandi dimensioni (di solito un array) per riferimento, per evitare di far saltare lo stack dei parametri, ma che l'oggetto non doveva essere modificato.

PASCAL ha aggiunto degli indicatori al lessico del design linguistico.

C ha fornito una chiamata per valore e ha simulato una chiamata per riferimento definendo un operatore kludge per restituire un puntatore a un oggetto arbitrario in memoria.

Le lingue successive copiarono C, soprattutto perché i progettisti non avevano mai visto nient'altro. Questo è probabilmente il motivo per cui la chiamata per valore è così popolare.

C ++ ha aggiunto un kludge in cima a C kludge per fornire chiamate per riferimento.

Ora, come risultato diretto di call-by-value vs. call-by-reference vs. call-by-pointer-kludge, C e C ++ (programmatori) hanno orribili mal di testa con puntatori const e puntatori a const (sola lettura) oggetti.

Ada è riuscita a evitare questo intero incubo.

Ada non ha esplicito call-by-value vs. call-by-reference. Piuttosto, Ada ha parametri (che possono essere letti ma non scritti), parametri out (che DEVONO essere scritti prima di poter essere letti) e parametri out, che possono essere letti e scritti in qualsiasi ordine. Il compilatore decide se un determinato parametro viene passato per valore o per riferimento: è trasparente per il programmatore.

Il passaggio per riferimento consente effetti collaterali non intenzionali molto difficili, difficili da rintracciare quando iniziano a causare comportamenti indesiderati.

Passa per valore, in particolare final, staticoppure i constparametri di input fanno scomparire l'intera classe di bug.

Le lingue immutabili sono ancora più deterministiche e più facili da ragionare e capire cosa sta succedendo e cosa ci si aspetta che esca da una funzione.

Perché tante lingue vengono passate per valore?

Il punto di suddividere grandi programmi in piccole subroutine è che puoi ragionare in modo indipendente sulle subroutine. Passa per riferimento rompe questa proprietà. (Come lo stato mutabile condiviso.)

Anche i linguaggi in cui hai una manipolazione esplicita del puntatore come C viene sempre passato per valore ( puoi passarli per riferimento ma non è il comportamento predefinito).

In realtà, C è sempre pass-by-value, mai pass-by-reference. Puoi prendere un indirizzo di qualcosa e passare quell'indirizzo, ma l'indirizzo verrà comunque passato per valore.

Qual è il vantaggio di questo, perché tante lingue sono passate per valori e perché altre sono passate per riferimento ?

Esistono due motivi principali per l'utilizzo del riferimento pass-by:

1. simulando più valori di ritorno
2. efficienza

Personalmente, penso che il n. 1 sia falso: è quasi sempre una scusa per cattive API e / o design del linguaggio:

1. Se hai bisogno di più valori di ritorno, non simularli, usa solo una lingua che li supporti.

2. Puoi anche simulare più valori di ritorno impacchettandoli in una struttura dati leggera come una tupla. Funziona particolarmente bene se il linguaggio supporta il pattern matching o il binding destrutturante. Ad esempio Ruby:

   def foo
     # This is actually just a single return value, an array: [1, 2, 3]
     return 1, 2, 3
   end
   
   # Ruby supports destructuring bind for arrays: a, b, c = [1, 2, 3]
   one, two, three = foo
   

3. Spesso, non hai nemmeno bisogno di più valori di ritorno. Ad esempio, un modello comune è che la subroutine restituisce un codice di errore e il risultato effettivo viene riscritto per riferimento. Invece, dovresti semplicemente lanciare un'eccezione se l'errore è imprevisto o restituire un Either<Exception, T>errore se previsto. Un altro modello è quello di restituire un valore booleano che indica se l'operazione ha avuto esito positivo e restituire il risultato effettivo come riferimento. Ancora una volta, se l'errore è inatteso, è consigliabile generare un'eccezione, se è previsto l'errore, ad esempio quando si cerca un valore in un dizionario, è necessario restituire Maybe<T>invece un .

Il pass-by-reference può essere più efficiente del pass-by-value, perché non è necessario copiare il valore.

(Capisco che Haskell è passato per riferimento anche se non ne sono sicuro).

No, Haskell non è un riferimento pass-by. Né è pass-by-value. Pass-by-reference e pass-by-value sono entrambe strategie di valutazione rigorose, ma Haskell non è rigorosa.

In effetti, la specifica Haskell non specifica alcuna particolare strategia di valutazione. La maggior parte delle implementazioni di Hakell usa una combinazione di chiamata per nome e chiamata per necessità (una variante di chiamata per nome con memoizzazione), ma lo standard non lo impone.

Si noti che anche per i linguaggi rigidi, non ha senso distinguere tra pass-by-reference o pass-by-value per i linguaggi funzionali poiché la differenza tra loro può essere osservata solo se si modifica il riferimento. Pertanto, l'implementatore è libero di scegliere tra i due, senza interrompere la semantica della lingua.

Esistono comportamenti diversi a seconda del modello chiamante della lingua, del tipo di argomenti e dei modelli di memoria della lingua.

Con semplici tipi nativi, il passaggio per valore consente di passare il valore dai registri. Questo può essere molto veloce poiché non è necessario caricare il valore dalla memoria né salvare. Una simile ottimizzazione è anche possibile semplicemente riutilizzando la memoria utilizzata dall'argomento una volta terminata la chiamata, senza rischiare di incasinare la copia del chiamante dell'oggetto. Se l'argomento fosse un oggetto temporaneo, probabilmente avresti salvato una copia completa in tal modo (C ++ 11 rende questo tipo di ottimizzazione ancora più evidente con il nuovo riferimento a destra e la sua semantica di spostamento).

In molti linguaggi OO (C ++ è più un'eccezione in questo contesto), non è possibile passare un oggetto per valore. Sei costretto a passarlo per riferimento. Questo rende il codice polimorfico per impostazione predefinita e sono più in linea con la nozione di istanze proprie di OO. Inoltre, se si desidera passare per valore, è necessario crearne una copia, riconoscendo il costo della prestazione che ha generato tale azione. In questo caso, la lingua sceglie per te l'approccio che è più probabile che ti dia le migliori prestazioni.

Nel caso di linguaggi funzionali, suppongo che passare per valore o riferimento sia semplicemente una questione di ottimizzazione. Poiché le funzioni in tale linguaggio sono pure e prive di effetti collaterali, non c'è davvero motivo di copiare il valore se non per la velocità. Sono anche abbastanza sicuro che un tale linguaggio spesso condividesse la stessa copia di oggetti con gli stessi valori, una possibilità disponibile solo se hai usato un semantico di riferimento passante (const). Python ha anche usato questo trucco per stringhe intere e comuni (come metodi e nomi di classe), spiegando perché interi e stringhe sono oggetti costanti in Python. Ciò aiuta anche a ottimizzare nuovamente il codice, consentendo ad esempio il confronto dei puntatori anziché il confronto dei contenuti e facendo una valutazione pigra di alcuni dati interni.

Puoi passare un'espressione per valore, è naturale. Passare l'espressione per riferimento (temporaneo) è ... strano.

Se passi per riferimento, allora stai effettivamente lavorando sempre con valori globali, con tutti i problemi dei globuli (ovvero portata ed effetti collaterali non intenzionali).

I riferimenti, proprio come i globali, a volte sono utili, ma non dovrebbero essere la tua prima scelta.