Lambda The Ultimate renvoie à l'idée que les lambdas du lambda-calcul peuvent implémenter efficacement chaque concept intégré dans tous les langages de programmation, passés, présents et futurs. Classes, Modules, Paquets, Objets, Méthodes, Flux de contrôle, Structures de données, Macros, Continuations, Coroutines, Générateurs, Compréhensions de liste, Flux, etc.
En l'occurrence, cette nature ultime implique de représenter une fonction anonyme. Mais les lambdas ne sont pas fondamentalement limités à des fonctions anonymes. On les enseigne de cette façon, mais l’essence de lambda est bien plus profonde que les fonctions mathématiques sans noms. En d'autres termes, je suis en désaccord avec:
Je comprends ce que signifie lambda, l’idée d’une fonction anonyme est à la fois simple et puissante, mais je ne comprends pas ce que «l’ultime» signifie dans ce contexte.
En pratique, l’utilisation de lambdas en tant qu’abstractions syntaxiques («macros»), qui ne sont pas appelées par valeur / applicatives (fonctions mathématiques utilisées), est absolument cruciale pour souscrire à l’idée que les lambdas peuvent réellement servir de base. noyau de chaque système de traitement de langage de programmation.
Pour la théorie: Il existe un lien intéressant entre le paradoxe de Bertrand Russell et les axiomes de la compréhension (et de l'extension) dans la théorie des ensembles naïve. Un lambda est aux fonctions ce que la notation de constructeur est à des ensembles: les lambdas sont des notations de constructeur de fonctions. Il existe une différence importante, généralement ignorée, entre (lambda (x) (* xx)) et ce à quoi elle correspond (la fonction qui met les carrés). Si l’on ne fait pas la distinction entre les deux en général, c’est-à-dire entre la notation et la dénotation (une erreur commise par Church et Frege), on a alors affaire à des paradoxes. Pour les décors et Frege, c'est le Barbier de Séville de Bertrand Russell qui illustre l'erreur. pour les fonctions et l'Eglise, c'est Halacle Oracle d'Alan Turing.
Notez que les paradoxes sont bons, pratiques. Nous voulons que EVAL soit exprimable, et nous voulons que lambdas signifie plus que des fonctions. Supposer que le contraire mène à la contradiction est le résultat souhaitable; c'est un bon test de bon sens: les lambdas ne peuvent être ultimes que s'ils n'expriment que de simples fonctions
Racket (anciennement PLT Scheme) continue de défendre l’idée que des langages de programmation pratiques peuvent vraiment être construits, à partir de la base, sur 'just lambda'.
Kernel , de Shutt, affirme que lambda n'est pas vraiment l'abstraction ultime. Il soutient qu'il existe un concept encore plus primitif (pour le grec, surnommé vau) que Sussman connaissait sous le nom de FEXPR.
Felleisin et compagnie (pour Racket) tirent une grande partie de la puissance de la vau de Shutt en utilisant le concept de phases , ou metalevels, qui correspond approximativement à l'exécution du code source à travers plusieurs étapes de la traduction (comme avec le prétraitement C, mais en utilisant le même langage à chaque fois). «étape» et les «étapes» ne sont pas en réalité totalement distinctes dans le temps). (Ainsi, ils soutiennent qu'un lambda dans une phase supérieure se rapproche suffisamment d'un vau.) En fait, ils affirment que les phases sont meilleures que les FEXPR, précisément parce qu'elles sont plus limitées; en bref, "les FEXPR sont trop puissants" (voir le travail de Wand, ce que Shutt soutient contre).
Le document 3-Lisp de Brian Smith, "Réflexion procédurale dans les langages de programmation", tente une reformulation rigoureuse de la théorie des langages de type LISP, en distinguant nettement les notations (symboles / langage / programmes) des dénotations (choses / références / valeurs / résultats). ) http://dspace.mit.edu/handle/1721.1/15961
"La théorie des FEXPRs est triviale" de Mitchell Wand envoie plus de clous dans le cercueil (temporaire?) Que Kent Pittman a créé pour les FEXPR (qui, comme Felleisen, soutient que les FEXPR rendent la compilation trop ardue).
Paul Graham affirme avec force et longuement dans "On Lisp" que le véritable pouvoir réside dans les lambdas en tant que transformateurs de syntaxe (macros), plutôt qu'en tant que transformateurs de valeurs (fonctions mathématiques). Le développement du lambda-calcul applicatif par Plotkin pourrait être considéré comme quelque peu contrasté, car Plotkin limite le calcul de Church à son sous-ensemble appel par valeur / applicatif. Bien entendu, la gestion efficace de la partie applicative est très importante. Il est donc important de développer une théorie spécialisée dans cette utilisation de lambda. (Plotkin et Graham ne se disputent pas.)
En fait, en général, la notion de Lambda en tant qu’ultime n’est qu’un de ces retournements dans le débat éternel entre efficacité et expressivité; c'est la position selon laquelle lambda est l'outil ultime de l'expressivité et, avec suffisamment d'études, s'avérera être également l'outil ultime de l'efficacité. En d’autres termes, nous pouvons, si nous le souhaitons, voir l’avenir des langages de programmation comme étant rien de plus, rien d’autre que l’étude de la manière de mettre efficacement en œuvre tous les fragments du calcul du lambda, qui présentent un intérêt pratique.
"Les 700 prochains langages de programmation" de Landin, http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf , est une référence accessible qui contribue au développement de ce concept selon lequel Lambda est Ultime.