He estado jugando con lenguajes de programación funcionales durante algunos años, y sigo encontrando esta frase. Por ejemplo, es un capítulo de "The Little Schemer", que ciertamente es anterior al blog con este nombre. (No, el capítulo no ayuda a responder mi pregunta).
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.
Lugares donde he visto esta frase:
- El título del capítulo 8 de The Little Schemer
- Un blog: http://lambda-the-ultimate.org/
- Una serie de documentos de "Lambda the ultimate X": http://library.readscheme.org/page1.html
Siento que me falta una referencia aquí, ¿alguien puede ayudarme?
functional-programming
terminology
history
lambda
Eric Wilson
fuente
fuente
Respuestas:
Sí, es simplemente una frase recurrente en el título de varios artículos, a partir de una pareja en los años 70, en la que Sussman y Steele demuestran el uso del cálculo lambda para la programación, por medio de un dialecto minimalista Lisp llamado " Esquema " que idearon para el propósito. Puedes encontrar los papeles ellos mismos aquí ; Son interesantes y sorprendentemente relevantes.
No estoy seguro de si esto se menciona explícitamente, pero está claro (por contexto, después de leer los documentos y conocer los antecedentes generales y los intereses de investigación de los autores) que la frase es simplemente un eslogan pegadizo para su afirmación de que las abstracciones lambda , como una primitiva computacional, no solo son universales en el sentido formal (de ser capaces de codificar cualquier programa de alguna manera, aunque sea incómodo), sino que son universales en el sentido práctico de que todos y cada uno de los constructos están presentes en otros idiomas, incluso aquellos que son preparado desde cero, se puede volver a implementar en un lenguaje basado en lambda de una manera que sea efectiva y natural de usar.
La frase repetida lleva a la forma generalizada obvia "para todas las X, lambda es la X definitiva", que es el sentido que generalmente he tomado como "Lambda the Ultimate" como el nombre del blog, y señala que LtU está preocupado por el lenguaje de programación Diseño y teoría. Irónicamente, LtU probablemente también sea uno de los mejores lugares para encontrar a alguien que pueda contarle algo para lo que lambda no es la implementación final. :]
Tenga en cuenta también que Sussman es uno de los autores de SICP , un libro de texto muy influyente que también usa el lenguaje Scheme y pasa bastante tiempo introduciendo abstracciones lambda como concepto.
fuente
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:
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.
fuente
Supongo que es simplemente una referencia a algunos documentos escritos por Sussman y Steele entre 1975 y 1980 llamados:
Ver artículo de Wikipedia.
fuente