Lambda The Ultimate se refiere a la idea de que las lambdas del cálculo lambda pueden implementar eficazmente cada concepto integrado en cada lenguaje de programación, pasado, presente y futuro. Clases, módulos, paquetes, objetos, métodos, flujo de control, estructuras de datos, macros, continuaciones, rutinas, generadores, comprensiones de listas, flujos, etc.
Resulta que esa naturaleza última incluye representar una función anónima. Pero las lambdas no están, en esencia, limitadas solo a funciones anónimas. Se les enseña de esa manera, pero la esencia de lambda va mucho más allá de las funciones matemáticas sin nombres. En otras palabras, estoy en desacuerdo con:
Entiendo lo que significa lambda, la idea de una función anónima es simple y poderosa, pero no entiendo qué significa "lo último" en este contexto.
Como cuestión práctica, el uso de lambdas como abstracciones sintácticas ('macros'), que no son llamadas por valor / aplicativas (que son las funciones matemáticas), es absolutamente crucial para aceptar la idea de que lambdas realmente puede servir como el núcleo de cada sistema de procesamiento de lenguaje de programación.
Para la teoría: hay una conexión interesante con la paradoja de Bertrand Russell y los axiomas de comprensión (y extensión) en la ingenua teoría de conjuntos. Una lambda es para funciones lo que la notación de generador de conjuntos es para conjuntos: las lambdas son notación de generador de funciones. Hay una diferencia importante, generalmente ignorada, entre (lambda (x) (* xx)) y lo que se evalúa como (la función que cuadra). Si uno no puede distinguir entre los dos en general, es decir, entre la notación y la denotación (un error que cometieron Church y Frege), entonces uno se enfrenta a las paradojas. Para sets y Frege, es el Barbero de Sevilla de Bertrand Russell el que ilustra el error; para funciones e Iglesia, es el Halting Oracle de Alan Turing.
Tenga en cuenta que las paradojas son buenas, prácticas, cosas. Queremos que EVAL sea expresable, y queremos que lambdas signifique más que solo funciones. Que asumir lo contrario conduce a la contradicción es el resultado deseable; sirve como una buena prueba de cordura: las lambdas difícilmente pueden ser lo último si solo expresan meras funciones.
Racket (anteriormente PLT Scheme) continúa persiguiendo la idea de que los lenguajes de programación prácticos realmente se pueden construir, desde cero, en 'solo lambda'.
Kernel , de Shutt, argumenta que lambda no es realmente la máxima abstracción. Sostiene que todavía hay un concepto más primitivo (para griego, denominado vau) que Sussman conocía como FEXPR.
Felleisin y compañía (para Racket) obtienen gran parte del poder de vat de Shutt al usar el concepto de fases o metaniveles, lo que significa aproximadamente ejecutar el código fuente a través de múltiples etapas de traducción (como con el preprocesamiento C, pero usando el mismo lenguaje en cada 'paso', y los 'pasos' en realidad no son completamente distintos en el tiempo). (Entonces, argumentan que una lambda en una fase superior se aproxima a un vau lo suficientemente bien). De hecho, argumentan que las fases son mejores que las FEXPR, precisamente por ser más limitadas; en resumen, "los FEXPR son demasiado poderosos" (ver el trabajo de Wand, contra el cual Shutt argumenta).
3-Lisp de Brian Smith, "Reflexión procesal en lenguajes de programación", intenta una reformulación rigurosa de la teoría de los lenguajes tipo LISP a lo largo de las líneas de notaciones distintivas (símbolos / lenguaje / programas) de denotaciones (cosas / referencias / valores / resultados ) http://dspace.mit.edu/handle/1721.1/15961
"The Theory of FEXPRs Trivial" de Mitchell Wand envía más clavos al ataúd (¿temporal?) Que Kent Pittman forjó para los FEXPR (que, como Felleisen, argumenta en contra de los FEXPR por hacer que la compilación sea demasiado difícil).
Paul Graham sostiene con fuerza y extensamente en "On Lisp" que el poder real es lambdas como transformadores de sintaxis (macros), en lugar de transformadores de valores (funciones matemáticas). El desarrollo de Plotkin del cálculo lambda aplicativo podría tomarse como algo contrastante, porque Plotkin limita el cálculo de Church a su subconjunto call-by-value / aplicative. Por supuesto, manejar la parte aplicativa de manera eficiente es muy importante, por lo que es importante desarrollar una teoría especializada para ese uso de lambda. (Plotkin y Graham no discuten unos contra otros).
De hecho, en general, la noción de Lambda como Ultimate es solo uno de esos giros en el debate eterno entre eficiencia y expresividad; Es la posición de que lambda es la herramienta definitiva para la expresividad y, dado el estudio suficiente, en última instancia, también será la herramienta definitiva para la eficiencia. En otras palabras, podemos, si queremos, ver el futuro de los lenguajes de programación como nada más y nada menos que el estudio de cómo implementar eficientemente todos los fragmentos prácticamente relevantes del cálculo lambda.
"Los siguientes 700 lenguajes de programación" de Landin, http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf , es una referencia accesible que contribuye al desarrollo de ese concepto de que Lambda es lo último.