Funzioni pure: "Nessun effetto collaterale" implica "Sempre lo stesso output, dato lo stesso input"?

Le due condizioni che definiscono una funzione puresono le seguenti:

1. Nessun effetto collaterale (ovvero sono consentite solo modifiche all'ambito locale)
2. Restituisce sempre lo stesso output, dato lo stesso input

Se la prima condizione è sempre vera, ci sono volte in cui la seconda condizione non è vera?

Cioè è davvero necessario solo con la prima condizione?

Ecco alcuni controesempi che non modificano l'ambito esterno ma sono comunque considerati impuri:

• function a() { return Date.now(); }
• function b() { return window.globalMutableVar; }
• function c() { return document.getElementById("myInput").value; }
• function d() { return Math.random(); } (che certamente cambia il PRNG, ma non è considerato osservabile)

L'accesso a variabili non locali non costanti è sufficiente per poter violare la seconda condizione.

Penso sempre alle due condizioni per la purezza come complementari:

• la valutazione del risultato non deve avere effetti sullo stato collaterale
• il risultato della valutazione non deve essere influenzato dallo stato laterale

Il termine effetto collaterale si riferisce solo al primo, la funzione che modifica lo stato non locale. Tuttavia, a volte anche le operazioni di lettura sono considerate effetti collaterali: quando sono operazioni e implicano anche la scrittura, anche se il loro scopo principale è accedere a un valore. Esempi di ciò sono la generazione di un numero pseudocasuale che modifica lo stato interno del generatore, la lettura da un flusso di input che fa avanzare la posizione di lettura o la lettura da un sensore esterno che implica un comando di "misura".

Il modo "normale" di esprimere cosa sia una funzione pura è in termini di trasparenza referenziale . Una funzione è pura se è referenzialmente trasparente .

Trasparenza referenziale , grosso modo, significa che puoi sostituire la chiamata alla funzione con il suo valore di ritorno o viceversa in qualsiasi punto del programma, senza cambiare il significato del programma.

Quindi, ad esempio, se i C printffossero referenzialmente trasparenti, questi due programmi dovrebbero avere lo stesso significato:

printf("Hello");

e

5;

e tutti i seguenti programmi dovrebbero avere lo stesso significato:

5 + 5;

printf("Hello") + 5;

printf("Hello") + printf("Hello");

Perché printf restituisce il numero di caratteri scritti, in questo caso 5.

Diventa ancora più ovvio con le voidfunzioni. Se ho una funzione void foo, allora

foo(bar, baz, quux);

dovrebbe essere lo stesso di

;

Cioè poiché foonon restituisce nulla, dovrei essere in grado di sostituirlo con nulla senza cambiare il significato del programma.

È chiaro, quindi, che né printfné foosono referenzialmente trasparenti, e quindi nessuno dei due è puro. Infatti, una voidfunzione non può mai essere referenzialmente trasparente, a meno che non sia una no-op.

Trovo questa definizione molto più facile da gestire come quella che hai dato. Permette anche di applicarlo a qualsiasi granularità tu voglia: puoi applicarlo a singole espressioni, a funzioni, a interi programmi. Ti permette, ad esempio, di parlare di una funzione come questa:

func fib(n):
    return memo[n] if memo.has_key?(n)
    return 1 if n <= 1
    return memo[n] = fib(n-1) + fib(n-2)

Possiamo analizzare le espressioni che compongono la funzione e concludere facilmente che non sono referenzialmente trasparenti e quindi non pure, poiché utilizzano una struttura dati mutabile, ovvero l' memoarray. Tuttavia, possiamo anche esaminare la funzione e vedere che è referenzialmente trasparente e quindi pura. Questa è talvolta chiamata purezza esterna , cioè una funzione che appare pura al mondo esterno, ma è implementata internamente impura.

Tali funzioni sono comunque utili, perché mentre l'impurità infetta tutto ciò che la circonda, l'interfaccia pura esterna costruisce una sorta di "barriera di purezza", dove l'impurità infetta solo le tre linee della funzione, ma non trapela nel resto del programma . Queste tre righe sono molto più facili da analizzare per la correttezza rispetto all'intero programma.

Mi sembra che la seconda condizione che hai descritto sia un vincolo più debole della prima.

Faccio un esempio, supponiamo di avere una funzione per aggiungerne uno che registri anche alla console:

function addOneAndLog(x) {
  console.log(x);
  return x + 1;
}

La seconda condizione che hai fornito è soddisfatta: questa funzione restituisce sempre lo stesso output quando viene fornito lo stesso input. Tuttavia, non è una funzione pura perché include l'effetto collaterale della registrazione alla console.

Una funzione pura è, in senso stretto, una funzione che soddisfa la proprietà della trasparenza referenziale . Questa è la proprietà che possiamo sostituire un'applicazione di funzione con il valore che produce senza modificare il comportamento del programma.

Supponiamo di avere una funzione che aggiunge semplicemente:

function addOne(x) {
  return x + 1;
}

Possiamo sostituire addOne(5)con 6qualsiasi parte del nostro programma e nulla cambierà.

Al contrario, non possiamo sostituire addOneAndLog(x)con il valore 6ovunque nel nostro programma senza modificare il comportamento perché la prima espressione risulta in qualcosa che viene scritto sulla console mentre la seconda no.

Consideriamo qualsiasi di questo comportamento aggiuntivo che si comporta addOneAndLog(x)oltre alla restituzione dell'output come un effetto collaterale .

Potrebbe esserci una fonte di casualità dall'esterno del sistema. Supponiamo che parte del calcolo includa la temperatura ambiente. Quindi l'esecuzione della funzione produrrà risultati ogni volta diversi a seconda dell'elemento esterno casuale della temperatura ambiente. Lo stato non viene modificato eseguendo il programma.

Tutto quello a cui riesco a pensare, comunque.

Il problema con le definizioni FP è che sono molto artificiali. Ogni valutazione / calcolo ha effetti collaterali sul valutatore. È teoricamente vero. Negare ciò mostra solo che gli apologeti della FP ignorano la filosofia e la logica: una "valutazione" significa cambiare lo stato di un ambiente intelligente (macchina, cervello, ecc.). Questa è la natura del processo di valutazione. Nessun cambiamento - nessun "calcolo". L'effetto può essere molto visibile: il riscaldamento della CPU o il suo guasto, lo spegnimento della scheda madre in caso di surriscaldamento e così via.

Quando parli di trasparenza referenziale, dovresti capire che le informazioni su tale trasparenza sono disponibili per l'essere umano come creatore dell'intero sistema e detentore di informazioni semantiche e potrebbero non essere disponibili per il compilatore. Ad esempio, una funzione può leggere una risorsa esterna e avrà una monade IO nella sua firma ma restituirà sempre lo stesso valore (ad esempio, il risultato di current_year > 0). Il compilatore non sa che la funzione restituirà sempre lo stesso risultato, quindi la funzione è impura ma ha proprietà referenzialmente trasparenti e può essere sostituita con Truecostante.

Quindi, per evitare tale imprecisione, dovremmo distinguere le funzioni matematiche e le "funzioni" nei linguaggi di programmazione. Le funzioni in Haskell sono sempre impure e la definizione di purezza ad esse correlata è sempre molto condizionale: funzionano su hardware reale con effetti collaterali reali e proprietà fisiche, il che è sbagliato per le funzioni matematiche. Ciò significa che l'esempio con la funzione "printf" è totalmente errato.

Ma non tutte le funzioni matematiche sono pure pure: ogni funzione che ha t(tempo) come parametro può essere impura: tcontiene tutti gli effetti e la natura stocastica della funzione: nel caso comune si ha un segnale in ingresso e non si ha idea dei valori effettivi, può essere anche un rumore.

Se la prima condizione è sempre vera, ci sono volte in cui la seconda condizione non è vera?

sì

Considera un semplice snippet di codice di seguito

public int Sum(int a, int b) {
    Random rnd = new Random();
    return rnd.Next(1, 10);
}

Questo codice restituirà un output casuale per lo stesso set di input, tuttavia non ha alcun effetto collaterale.

L'effetto complessivo di entrambi i punti # 1 e # 2 che hai menzionato quando combinati insieme significa: In qualsiasi momento se la funzione Sumcon lo stesso i / p viene sostituita con il suo risultato in un programma, il significato generale del programma non cambia . Questo non è altro che trasparenza referenziale .