come un linguaggio di programmazione funzionale puro gestisce senza istruzioni di assegnazione?

Leggendo il famoso SICP, ho scoperto che gli autori sembrano piuttosto riluttanti a presentare la dichiarazione di incarico a Scheme nel capitolo 3. Ho letto il testo e ho capito perché si sentono così.

Dato che Scheme è il primo linguaggio di programmazione funzionale di cui io abbia mai saputo qualcosa, sono un po 'sorpreso che ci siano alcuni linguaggi di programmazione funzionale (non Scheme ovviamente) che possono fare a meno dei compiti.

Usiamo l'esempio offerto dal libro, l' bank accountesempio. Se non è presente alcuna istruzione di assegnazione, come è possibile farlo? Come modificare la balancevariabile? Lo chiedo perché so che ci sono alcuni cosiddetti linguaggi funzionali puri là fuori e secondo la teoria completa di Turing, anche questo può essere fatto.

Ho imparato C, Java, Python e uso molto i compiti in ogni programma che ho scritto. Quindi è davvero un'esperienza che apre gli occhi. Spero davvero che qualcuno possa spiegare brevemente come vengono evitati gli incarichi in quei linguaggi di programmazione funzionale e quale impatto profondo (se presente) ha su questi linguaggi.

L'esempio sopra menzionato è qui:

(define (make-withdraw balance)
    (lambda (amount)
        (if (>= balance amount)
            (begin (set! balance (- balance amount))
                balance)
            "Insufficient funds")))

Questo ha cambiato il balanceby set!. Per me sembra un metodo di classe cambiare il membro della classe balance.

Come ho detto, non ho familiarità con i linguaggi di programmazione funzionale, quindi se ho detto qualcosa di sbagliato su di loro, sentiti libero di sottolineare.

Se non è presente alcuna istruzione di assegnazione, come è possibile farlo? Come modificare la variabile di saldo?

Non è possibile modificare le variabili senza una sorta di operatore di assegnazione.

Lo chiedo perché so che ci sono alcuni cosiddetti linguaggi funzionali puri là fuori e secondo la teoria completa di Turing, anche questo può essere fatto.

Non proprio. Se una lingua è Turing completa, ciò significa che può calcolare qualsiasi cosa possa calcolare qualsiasi altra lingua completa di Turing. Ciò non significa che debba avere tutte le funzionalità di altre lingue.

Non è una contraddizione che un linguaggio di programmazione completo di Turing non abbia modo di modificare il valore di una variabile, purché per ogni programma che abbia variabili mutabili, puoi scrivere un programma equivalente che non abbia variabili mutabili (dove "equivalente" significa che calcola la stessa cosa). E in effetti ogni programma può essere scritto in questo modo.

Per quanto riguarda il tuo esempio: in un linguaggio puramente funzionale semplicemente non saresti in grado di scrivere una funzione che restituisce un diverso saldo del conto ogni volta che viene chiamato. Ma saresti ancora in grado di riscrivere ogni programma, che utilizza tale funzione, in modo diverso.

Dato che hai chiesto un esempio, consideriamo un programma imperativo che utilizza la tua funzione make -draw (in pseudo-codice). Questo programma consente all'utente di prelevare da un conto, depositare su di esso o richiedere la quantità di denaro nel conto:

account = make-withdraw(0)
ask for input until the user enters "quit"
    if the user entered "withdraw $x"
        account(x)
    if the user entered "deposit $x"
        account(-x)
    if the user entered "query"
        print("The balance of the account is " + account(0))

Ecco un modo per scrivere lo stesso programma senza usare variabili mutabili (non mi preoccuperò di IO referenzialmente trasparente perché la domanda non era su questo):

function IO_loop(balance):
    ask for input
    if the user entered "withdraw $x"
        IO_loop(balance - x)
    if the user entered "deposit $x"
        IO_loop(balance + x)
    if the user entered "query"
        print("The balance of the account is " + balance)
        IO_loop(balance)
    if the user entered "quit"
        do nothing

 IO_loop(0)

La stessa funzione potrebbe anche essere scritta senza usare la ricorsione usando una piega sull'input dell'utente (che sarebbe più idiomatica della ricorsione esplicita), ma non so se hai ancora familiarità con le pieghe, quindi l'ho scritto in un modo che non usa ancora nulla di sconosciuto.

Hai ragione che assomiglia molto a un metodo su un oggetto. Questo perché è essenzialmente quello che è. La lambdafunzione è una chiusura che tira la variabile esterna balancenel suo ambito. Avere più chiusure che si chiudono sulle stesse variabili esterne e avere più metodi sullo stesso oggetto sono due diverse astrazioni per fare esattamente la stessa cosa, e l'una o l'altra possono essere implementate in termini dell'altra se si capiscono entrambi i paradigmi.

Il modo in cui i linguaggi funzionali puri gestiscono lo stato è imbrogliare. Ad esempio, in Haskell se vuoi leggere l'input da una fonte esterna, (che non è deterministica, ovviamente, e non necessariamente darà lo stesso risultato due volte se lo ripeti), usa un trucco da monade per dire "abbiamo abbiamo questa altra finta variabile che rappresenta lo stato dell'intero resto del mondo , e non possiamo esaminarlo direttamente, ma leggere l'input è una funzione pura che prende lo stato del mondo esterno e restituisce l'input deterministico a quello stato esatto renderà sempre, oltre al nuovo stato del mondo esterno ". (Questa è una spiegazione semplificata, ovviamente. Leggere sul modo in cui funziona effettivamente ti spezzerà il cervello.)

O nel caso del problema del tuo conto bancario, invece di assegnare un nuovo valore alla variabile, può restituire il nuovo valore come risultato della funzione, e quindi il chiamante deve gestirlo in uno stile funzionale, generalmente ricreando tutti i dati che fa riferimento a quel valore con una nuova versione contenente il valore aggiornato. (Questa non è un'operazione così voluminosa come potrebbe sembrare se i tuoi dati sono impostati con il giusto tipo di struttura ad albero.)

"Operatori ad assegnazione multipla" è un esempio di una caratteristica del linguaggio che, in generale, ha effetti collaterali ed è incompatibile con alcune proprietà utili dei linguaggi funzionali (come la valutazione pigra).

Ciò, tuttavia, non significa che l'assegnazione in generale sia incompatibile con un puro stile di programmazione funzionale (vedi questa discussione per esempio), né significa che non puoi costruire una sintassi che consenta azioni che assomigliano ad assegnazioni in generale, ma sono implementati senza effetti collaterali. Creare quel tipo di sintassi e scrivere programmi efficienti in esso, tuttavia, richiede tempo e è difficile.

Nel tuo esempio specifico, hai ragione: il set! l'operatore è un incarico. È non un operatore libero effetto collaterale, ed è un luogo dove pause Schema con un approccio puramente funzionale alla programmazione.

In ultima analisi, qualsiasi linguaggio puramente funzionale è costretta a rompere con l'approccio a volte puramente funzionale - la stragrande maggioranza dei programmi utili farlo ha effetti collaterali. La decisione su dove farlo è di solito una questione di convenienza e i progettisti linguistici cercheranno di offrire al programmatore la massima flessibilità nel decidere dove rompere con un approccio puramente funzionale, come appropriato per il loro programma e dominio problematico.

In un linguaggio puramente funzionale, si programmerebbe un oggetto di conto bancario come una funzione di trasformazione del flusso. L'oggetto è considerato come una funzione da un flusso infinito di richieste dai proprietari dell'account (o chiunque) a un flusso potenzialmente infinito di risposte. La funzione inizia con un saldo iniziale ed elabora ciascuna richiesta nel flusso di input per calcolare un nuovo saldo, che viene quindi ricondotto alla chiamata ricorsiva per elaborare il resto del flusso. (Ricordo che la SICP discute il paradigma del trasformatore di flusso in un'altra parte del libro.)

Una versione più elaborata di questo paradigma si chiama "programmazione reattiva funzionale" discussa qui su StackOverflow .

Il modo ingenuo di fare i trasformatori di flusso ha alcuni problemi. È possibile (in effetti, abbastanza semplice) scrivere programmi buggy che mantengano tutte le vecchie richieste in giro, sprecando spazio. Più seriamente, è possibile fare in modo che la risposta alla richiesta corrente dipenda da richieste future. Le soluzioni a questi problemi sono attualmente in fase di elaborazione. Neel Krishnaswami è la forza dietro di loro.

Disclaimer : non appartengo alla chiesa della pura programmazione funzionale. In effetti, non appartengo a nessuna chiesa :-)

Non è possibile rendere funzionale un programma al 100% se si prevede che faccia qualcosa di utile. (Se gli effetti collaterali non sono necessari, allora l'intero pensiero potrebbe essere stato ridotto a un tempo di compilazione costante) Come nell'esempio di prelievo puoi rendere funzionali la maggior parte delle procedure ma alla fine avrai bisogno di procedure con effetti collaterali (input dell'utente, uscita su console). Detto questo, puoi rendere funzionale la maggior parte del tuo codice e quella parte sarà facile da testare, anche automaticamente. Quindi si crea un codice imperativo per eseguire l'input / output / database / ... che richiederebbe il debug, ma mantenendo pulita la maggior parte del codice non sarà troppo lavoro. Userò il tuo esempio di prelievo:

(define +no-founds+ "Insufficient funds")

;; functional withdraw
(define (make-withdraw balance amount)
    (if (>= balance amount)
        (- balance amount)
        +no-founds+))

;; functional atm loop
(define (atm balance thunk)
  (let* ((amount (thunk balance)) 
         (new-balance (make-withdraw balance amount)))
    (if (eqv? new-balance +no-founds+)
        (cons +no-founds+ '())
        (cons (list 'withdraw amount 'balance new-balance) (atm new-balance thunk)))))

;; functional balance-line -> string 
(define (balance->string x)
  (if (eqv? x +no-founds+)
      (string-append +no-founds+ "\n")
      (if (null? x)
          "\n"
          (let ((first-token (car x)))
            (string-append
             (cond ((symbol? first-token) (symbol->string first-token))
                   (else (number->string first-token)))
             " "
             (balance->string (cdr x)))))))

;; functional thunk to test  
(define (input-10 x) 10) ;; define a purly functional input-method

;; since all procedures involved are functional 
;; we expect the same result every time.
;; we use this to test atm and make-withdraw
(apply string-append (map balance->string (atm 100 input-10)))

;; no program can be purly functional in any language.
;; From here on there are imperative dirty procedures!

;; A procedure to get input from user is needed. 
;; Side effects makes it imperative
(define (user-input balance)
  (display "You have $")
  (display balance)
  (display " founds. How much to withdraw? ")
  (read))

;; We need a procedure to print stuff to the console 
;; as well. Side effects makes it imperative
(define (pretty-print-result x)
  (for-each (lambda (x) (display (balance->string x))) x))

;; use imperative procedure with atm.
(pretty-print-result (atm 100 user-input))

È possibile fare lo stesso in quasi tutte le lingue e produrre gli stessi risultati (meno bug), anche se potrebbe essere necessario impostare variabili temporanee all'interno di una procedura e persino mutare roba, ma questo non importa tanto quanto la procedura in realtà agisce in modo funzionale (i soli parametri determinano il risultato). Credo che diventerai un programmatore migliore in qualsiasi lingua dopo aver programmato un po 'di LISP :)

L'assegnazione è una cattiva operazione perché divide lo spazio degli stati in due parti, prima dell'assegnazione e dopo l'assegnazione. Ciò causa difficoltà nel tenere traccia di come le variabili vengono modificate durante l'esecuzione del programma. Le seguenti cose nei linguaggi funzionali stanno sostituendo i compiti:

1. Parametri funzione collegati direttamente ai valori restituiti
2. scegliendo diversi oggetti da restituire invece di modificare oggetti esistenti.
3. creando nuovi valori valutati in modo pigro
4. elencando tutti gli oggetti possibili , non solo quelli che devono essere in memoria
5. nessun effetto collaterale