Il Lambda Calculus è puramente sintattico?

Ho letto alcune settimane sul Calcolo Lambda, ma non ho ancora visto nulla di materialmente distinto dalle funzioni matematiche esistenti e voglio sapere se è solo una questione di notazione o se ci sono nuove proprietà o regole create dagli assiomi del calcolo lambda che non si applicano ad ogni funzione matematica. Quindi, per esempio, ho letto che:

"Ci possono essere funzioni anonime" : le funzioni Lambda non sono anonime, sono tutte chiamate lambda. In notazione matematica è consentito utilizzare la stessa variabile per funzioni diverse se il nome non è importante. Ad esempio, le due funzioni in una connessione Galois sono spesso chiamate entrambe *.

"Le funzioni possono accettare funzioni come input" : non è possibile farlo con le normali funzioni.

"Le funzioni sono scatole nere" : solo input e output sono anche descrizioni valide di funzioni matematiche ...

Potrebbe sembrare una discussione o una domanda supponente, ma credo che ci dovrebbe essere una risposta "corretta" a questa domanda. Voglio sapere se il calcolo lambda è solo una convenzione notazionale o sintattica per lavorare con funzioni matematiche, o se ci sono differenze sostanziali o semantiche tra lambda e funzioni ordinarie.

Ironia della sorte, il titolo è giusto ma non nel modo in cui sembra significare che è "è il calcolo lambda solo una convenzione notazionale" che non è accurato.

I termini lambda non sono funzioni ¹ . Sono pezzi di sintassi, cioè raccolte di simboli su una pagina. Abbiamo regole per manipolare queste raccolte di simboli, in particolare la riduzione beta. È possibile avere più distinte lambda termini che corrispondono alla stessa funzione. ²

Affronterò i tuoi punti direttamente.

Innanzitutto, lambda non è un nome che viene riutilizzato. Non solo sarebbe estremamente confuso, ma non scriveremo $\lambda(x)$ (o $(\lambda\ x)$ ) che è quello che faremmo se $\lambda$ fosse un nome per una funzione, proprio come scriviamo $f(x)$ . In $f(x)$ potremmo sostituire $f$ (se fosse definito da un termine lambda) con il termine lambda producendo qualcosa di simile$(\lambda y.y)(x)$ significa$(\lambda y.y)$ è un'espressione che può rappresentare una funzione, non una dichiarazione che dichiara una funzione (chiamata$\lambda$ o qualsiasi altra cosa). Ad ogni modo, quando sovraccarichiamo la terminologia / notazione, è (si spera) fatto in un modo in cui può essere chiarito dal contesto, che certamente non può essere il caso dei termini lambda.

Il tuo prossimo punto va bene ma in qualche modo irrilevante. Questa non è una competizione in cui ci sono termini e funzioni del team Lambda e solo uno può vincere. Una delle principali applicazioni dei termini lambda è lo studio e la comprensione di alcuni tipi di funzioni. Un polinomio non è una funzione, sebbene spesso li identifichiamo in modo sciatto. Studiare i polinomi non significa che si pensi che tutte le funzioni dovrebbero essere polinomi, né è il caso che i polinomi debbano "fare" qualcosa "nuovo" per cui valga la pena studiare.

Le funzioni teoriche impostate non sono scatole nere, sebbene siano interamente definite dalla loro relazione input-output. (Essi letteralmente sono loro rapporto input-output.) Termini lambda sono anche non scatole nere e sono non definite dalla loro relazione di ingresso-uscita. Come ho detto prima, puoi avere termini lambda distinti che producono la stessa relazione input-output. Ciò sottolinea anche il fatto che i termini lambda non possono essere funzioni, sebbene possano indurre funzioni. ²

In effetti, l'analogia tra polinomi e termini lambda è molto stretta, e sospetto che potresti non apprezzare la distinzione tra un polinomio e la funzione che rappresenta, quindi elaborerò un po '. ³ In genere quando vengono introdotti polinomi, di solito con coefficienti reali, vengono trattati come funzioni reali di un tipo particolare. Consideriamo ora la teoria dei registri a scorrimento a retroazione lineare (LFSR). È in gran parte la teoria dei polinomi (uni-variate) su $\mathbb F_2$ , ma se la consideriamo come una funzione $\mathbb F_2\to\mathbb F_2$ , allora ci sono al massimo $4$ tali funzioni. Vi è, tuttavia, un numero infinito di polinomi su $\mathbb F_2$ . ⁴Un modo per vedere questo è che possiamo interpretare questi polinomi come qualcosa di diverso dallefunzioni$\mathbb F_2\to\mathbb F_2$ , anzi qualsiasialgebra$\mathbb F_2$ farà. Per gli LFSR, interpretiamo comunemente i polinomi come operazioni su flussi di bit, che, se lo desiderassimo, potrebbero essere rappresentati come funzioni$\mathbf{2}^{\mathbb N}\to\mathbf{2}^{\mathbb N}$ , sebbene la stragrande maggioranza di tali funzioni non sarebbe nell'immagine dell'interpretazione di un LFSR.

Questo vale anche per i termini lambda, possiamo interpretarli entrambi come cose diverse dalle funzioni. Sono anche entrambi oggetti molto più tracciabili con cui lavorare rispetto agli insiemi di funzioni tipicamente infiniti. Sono entrambi molto più computazionali delle funzioni arbitrarie. Sono in grado di scrivere un programma per manipolare i polinomi (con coefficienti che sono almeno calcolabili in modo calcolabile) e termini lambda. In effetti, i termini lambda non tipizzati sono uno dei modelli originali di funzioni calcolabili. Questa prospettiva più simbolica / sintattica, calcolativa / computazionale è di solito più enfatizzata, specialmente per il calcolo lambda non tipizzato , rispetto alle interpretazioni più semantiche del calcolo lambda. Typedi termini lambda sono cose molto più gestibili e di solito (ma non sempre) possono essere facilmente interpretati come funzioni teoriche stabilite, ma possono anche essere interpretati in una classe di cose ancora più ampia oltre alle funzioni rispetto al calcolo lambda non tipizzato. Hanno anche una ricca teoria sintattica e una connessione molto profonda alla logica .

¹ È possibile che il problema potrebbe andare diversamente. Forse hai un'idea sbagliata di cosa sia una funzione.

² Questo in realtà non è così semplice. Per il calcolo lambda non tipizzato , non ha davvero senso interpretare ingenuamente termini lambda arbitrari come funzioni set-teoriche . Puoi iniziare a vedere questo quando provi ad articolare quale dovrebbe essere il dominio dell'interpretazione. Se interpreto un termine lambda come elemento di un insieme $D$ , voglio anche essere in grado di interpretarlo come una funzione su $D$ e in $D$ poiché desidero interpretare l'applicazione come applicazione di funzione. Si finisce con $D^D\subseteq D$ (o un indebolimento di questo) che è vero solo per l'insieme singleton. Ciò di cui abbiamo bisogno per il calcolo lambda non tipizzato è un oggetto riflessivoe per la categoria di insiemi non ci sono oggetti riflessi non banali. La storia è piuttosto diversa per i termini lambda digitati , ma può ancora essere non banale.

³ Se sei chiaro su questa distinzione, allora l'analogia dovrebbe essere piuttosto istruttiva.

⁴ Questo problema non si verifica con campi con caratteristica 0, come numeri complessi, reali, razionali o numeri interi, quindi la distinzione non è così netta, sebbene esista ancora.

Pensa al concetto di variabili. Nelle vecchie lingue come base, non avevi un'allocazione dinamica e avevi bisogno di un nome per ogni variabile. (Questo non è perfettamente accurato perché avevi array, ma l'idea è che ...) in molti problemi, devi essere in grado di allocare tutte le variabili che vuoi, senza essere limitato dal numero di nomi definiti dal tuo programma.

Le funzioni Lambda ti consentono di eliminare la stessa limitazione relativa ai nomi delle funzioni, consentendo al tuo programma di definire tutte le funzioni di cui ha bisogno e di "memorizzarle" nelle strutture di dati complesse degli stessi come altre variabili. Questo non è qualcosa che potresti fare con le funzioni convenzionali nominate.