Lambda The Ultimate refere-se à idéia de que as lambdas do lambda-calculus podem efetivamente implementar todos os conceitos incorporados em todas as linguagens de programação, passado, presente e futuro. Classes, Módulos, Pacotes, Objetos, Métodos, Fluxo de Controle, Estruturas de Dados, Macros, Continuações, Corotinas, Geradores, Compreensões de Lista, Fluxos e assim por diante.
Por acaso, essa natureza última inclui representar uma função anônima. Porém, as lambdas não se limitam apenas a funções anônimas. Eles são ensinados dessa maneira, mas a essência do lambda é muito mais profunda do que as funções matemáticas sem nome. Em outras palavras, discordo de:
Entendo o que lambda significa, a idéia de uma função anônima é simples e poderosa, mas não entendo o que "o máximo" significa neste contexto.
Por uma questão prática, o uso de lambdas como abstrações sintáticas ('macros'), que não são chamadas por valor / aplicativo (que funções matemáticas são), é absolutamente crucial para se adotar a ideia de que as lambdas realmente podem servir como núcleo de todo sistema de processamento de linguagem de programação.
Para a teoria: Há uma conexão interessante com o paradoxo de Bertrand Russell e os axiomas da compreensão (e extensão) na teoria ingênua dos conjuntos. Um lambda é para funções que a notação de construtor de conjuntos é para conjuntos: lambdas são notações de construtores de funções. Há uma diferença importante, geralmente ignorada, entre (lambda (x) (* xx)) e o que isso avalia (a função que esquadrinha). Se alguém não consegue distinguir entre os dois em geral, isto é, entre a notação e a denotação (um erro que Church e Frege cometeram), então se depara com paradoxos. Para sets e Frege, é o Barbeiro de Sevilha de Bertrand Russell que ilustra o erro; para funções e Igreja, é o Halting Oracle de Alan Turing.
Note que os paradoxos são coisas boas, práticas. Queremos que EVAL seja expressável e queremos que lambdas signifique mais do que apenas funções. Que assumir o contrário leva à contradição é o resultado desejável; serve como um bom teste de sanidade: as lambdas dificilmente podem ser definitivas se expressarem apenas meras funções.
Racket (anteriormente PLT Scheme) continua a processar a idéia de que linguagens de programação práticas realmente podem ser construídas, desde o início, em 'just lambda'.
Kernel , de Shutt, argumenta que o lambda não é realmente a abstração máxima. Ele argumenta que ainda existe um conceito mais primitivo (para o grego, apelidado de vau), que Sussman era conhecido como FLEX.
Felleisin e companhia (para Racket) obtêm grande parte do poder do vau de Shutt usando o conceito de fases ou níveis de metal, o que significa aproximadamente executar o código-fonte em vários estágios de tradução (como no pré-processamento C, mas usando o mesmo idioma em cada 'step', e os 'steps' não são realmente completamente distintos no tempo). (Portanto, eles argumentam que um lambda em uma fase superior se aproxima bastante de um vau.) De fato, eles argumentam que as fases são melhores que as FDPs, precisamente por serem mais limitadas; em resumo, "os FDPs são muito poderosos" (veja o trabalho de Wand, contra o qual Shutt argumenta).
O 3-Lisp de Brian Smith, "Reflexão processual nas linguagens de programação", tenta uma reformulação rigorosa da teoria das linguagens do tipo LISP, seguindo as linhas de notação distintamente acentuada (símbolos / idioma / programas) das denotações (coisas / referências / valores / resultados ) http://dspace.mit.edu/handle/1721.1/15961
Mitchell Wand, "The Theory of FRLs is Trivial", envia mais pregos para o caixão (temporário?) Que Kent Pittman criou para os FLEXs (que, como Felleisen, argumenta contra os FLEXs por tornar a compilação muito difícil).
Paul Graham argumenta com força e detalhadamente em "On Lisp" que o poder real é lambdas como transformadores de sintaxe (macros), e não como transformadores de valores (funções matemáticas). O desenvolvimento de Plotkin do cálculo lambda aplicado pode ser considerado um pouco contrastante, porque Plotkin limita o cálculo de Church ao seu subconjunto de chamada por valor / aplicativo. Obviamente, lidar com a parte aplicativa de forma eficiente é muito importante, por isso é importante desenvolver uma teoria especializada para o uso de lambda. (Plotkin e Graham não discutem um contra o outro.)
De fato, em geral, a noção de Lambda como Ultimate é apenas uma dessas reviravoltas no eterno debate entre eficiência e expressividade; é a posição de que o lambda é a melhor ferramenta para expressividade e, com bastante estudo, acabará por se mostrar a melhor ferramenta para eficiência também. Em outras palavras, podemos, se quisermos, ver o futuro das linguagens de programação como nada mais e nada menos que o estudo de como implementar eficientemente todos os fragmentos praticamente relevantes do cálculo lambda.
"As Próximas 700 Linguagens de Programação" de Landin, http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf , é uma referência acessível que contribui para o desenvolvimento desse conceito de que Lambda é Ultimate.