Lambda The Ultimate si riferisce all'idea che le lambda di lambda-calcolo possono implementare efficacemente ogni concetto incorporato in ogni linguaggio di programmazione, passato, presente e futuro. Classi, moduli, pacchetti, oggetti, metodi, flusso di controllo, strutture dati, macro, continuazioni, coroutine, generatori, comprensioni di elenchi, stream e così via.
Accade che la natura ultima includa la ricerca di una funzione anonima. Ma i lambda non sono, in sostanza, limitati a funzioni anonime. Vengono insegnati in quel modo, ma l'essenza di lambda va molto più in profondità delle funzioni matematiche senza nomi. In altre parole, ho problemi con:
Capisco cosa significa lambda, l'idea di una funzione anonima è sia semplice che potente, ma non riesco a capire cosa significhi "il massimo" in questo contesto.
In pratica, l'uso delle lambda come astrazioni sintattiche ("macro"), che non sono chiamate per valore / applicative (quali sono le funzioni matematiche), è assolutamente cruciale per acquisire l'idea che le lambda possano davvero servire da nucleo di ogni sistema di elaborazione del linguaggio di programmazione.
Per la teoria: esiste una connessione interessante con il paradosso di Bertrand Russell e gli assiomi della comprensione (e dell'estensione) nella teoria degli insiemi ingenui. Una lambda è funzioni che notazione set-builder è per set: le lambda sono notazioni builder-funzione. C'è una differenza importante, di solito ignorata, tra (lambda (x) (* xx)) e ciò che valuta (la funzione che quadra). Se uno non riesce a distinguere tra i due in generale, cioè tra notazione e denotazione (un errore commesso da Church e Frege), allora si scontrano con i paradossi. Per set e Frege, è il barbiere di Siviglia di Bertrand Russell che illustra l'errore; per le funzioni e la Chiesa, è l'Halting Oracle di Alan Turing.
Nota che i paradossi sono cose buone, pratiche. Vogliamo che EVAL sia espressibile e vogliamo che lambda significhi più che semplici funzioni. Che assumere il contrario porti alla contraddizione è il risultato desiderabile; serve come un bel test di sanità mentale: le lambda difficilmente possono essere definitive se esprimono solo semplici funzioni.
Racket (precedentemente PLT Scheme) continua a perseguire l'idea che i linguaggi di programmazione pratica possano davvero essere costruiti, da zero, su "just lambda".
Kernel , di Shutt, sostiene che lambda non è in realtà la massima astrazione. Sostiene che esiste ancora un concetto più primitivo (per il greco, soprannominato vau) che era noto a Sussman come FEXPR.
Felleisin e la compagnia (per Racket) ottengono gran parte della potenza del vau di Shutt usando il concetto di fasi , o metalevel, il che significa approssimativamente far funzionare il codice sorgente attraverso più fasi di traduzione (come con la preelaborazione C, ma usando la stessa lingua in ogni "step" e i "step" non sono in realtà completamente distinti nel tempo). (Quindi, sostengono che una lambda in una fase superiore si avvicina abbastanza bene a un vau.) In realtà, sostengono che le fasi sono migliori degli FEXPR, proprio per essere più limitate; in breve, "i FEXPR sono troppo potenti" (vedi il lavoro di Wand, contro cui Shutt discute).
Il 3-Lisp di Brian Smith, "Riflessione procedurale nei linguaggi di programmazione", tenta una rigorosa riformulazione della teoria dei linguaggi simili a LISP lungo le linee di notazioni nettamente distinte (simboli / linguaggio / programmi) da denotazioni (cose / riferimenti / valori / risultati ). http://dspace.mit.edu/handle/1721.1/15961
"The Theory of FEXPRs is Trivial" di Mitchell Wand manda più chiodi nella bara (temporanea?) Che Kent Pittman ha realizzato per gli FEXPR (che, come Felleisen, discute contro gli FEXPR perché rende la compilation troppo dura).
Paul Graham sostiene con forza e in dettaglio in "On Lisp" che il vero potere è lambda come trasformatori di sintassi (macro), piuttosto che come trasformatori di valori (funzioni matematiche). Lo sviluppo di Plotkin del lambda-calcolo applicativo potrebbe essere considerato in qualche modo contrastante, poiché Plotkin limita il calcolo di Church al suo sottoinsieme call-by-value / applicativo. Naturalmente, gestire la parte applicativa in modo efficiente è molto importante, quindi è importante sviluppare una teoria specializzata nell'uso di lambda. (Plotkin e Graham non discutono l'uno contro l'altro.)
In effetti, in generale, la nozione di Lambda come Ultimate è solo una di queste svolte sull'eterno dibattito tra efficienza ed espressività; è la posizione che lambda è lo strumento ultimo per espressività e, dato uno studio sufficiente, alla fine si dimostrerà anche lo strumento ultimo per l'efficienza. In altre parole, possiamo, se vogliamo, vedere il futuro dei linguaggi di programmazione come niente di più e niente di meno che lo studio di come implementare in modo efficiente tutti i frammenti praticamente rilevanti del calcolo lambda.
"I prossimi 700 linguaggi di programmazione" di Landin, http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf , è un riferimento accessibile che contribuisce allo sviluppo di quel concetto secondo cui Lambda è Ultimate.