Cómo el lenguaje funcional es diferente del punto de vista de implementación del lenguaje

Question

Existe todo el nuevo paradigma de "programación funcional", que necesita un cambio total de patrones de pensamiento en comparación con la programación de procedimientos. Utiliza funciones de orden superior, pureza, mónadas, etc., que no solemos ver en lenguajes imperativos y orientados a objetos.

Mi pregunta es cómo la aplicación de estos idiomas se diferencia de los lenguajes imperativos u orientado a objetos, con respecto a, por ejemplo, la gestión de memoria o internos como punteros, etc ..

Hay lenguajes funcionales que se ejecutan en parte superior de la JVM. ¿Esto significa que estos idiomas funcionan internamente como los otros idiomas en la JVM?

Answer 1

Las implementaciones de lenguajes de programación funcional utilizan una amplia gama de técnicas de implementación. Una excelente introducción a la implementación de Scheme (un dialecto Lisp) da este libro: Lisp in Small Pieces por Christian Queinnec.

Answer 2

Todo funciona en el mismo procesador (y, por lo tanto, con las mismas instrucciones de ensamblaje), de modo que, mientras avance lo suficiente, todo será lo mismo internamente.

Answer 3

supongo que hay muchos aspectos que se benefician de una atención especial en los lenguajes funcionales, uno que viene a la mente es:

Los lenguajes funcionales utilizan recursividad mucho. Entonces, cualquier implementación debería intentar optimizar este caso. P.ej. identifique la recursividad de la cola y transfórmela en un bucle internamente (ahorrándole así los gastos generales de llamadas a la función como guardar/restaurar pila). (http://en.wikipedia.org/wiki/Tail_recursion)

Answer 4

La implementación de un lenguaje de programación funcional como Haskell suele ser muy diferente a la de los lenguajes imperativos. Puede leer sobre una forma de hacerlo here. Aunque el documento tiene varios años, creo que las ideas todavía se usan.

Answer 5

El código resultante de los lenguajes funcionales usa muchas funciones que se ven en distintos grados en idiomas no funcionales. La recolección de basura ha pasado a uso general. La optimización de llamada de cola es done in GCC and VC++.

Los cierres, sin embargo, son un sello distintivo de la programación funcional. No ves uno sin el otro. Si define "lenguajes funcionales" para referirse solo a lenguajes funcionales puros, los dos no son sinónimos, ya que encuentra cierres en lenguajes imperativos que soportan programación funcional (por ejemplo, Javascript y Scheme (que es técnicamente imperativo, aunque el paradigma funcional es usado)). Los cierres pueden implementarse con un spaghetti stack para la pila de llamadas, o copiando variables locales al salir de un marco de pila, o asignando variables locales en el montón y dejando que la recolección de basura se encargue de ellas.

Una vez que tiene cierres, las funciones anónimas son relativamente fáciles (con un intérprete, son realmente fáciles). Con un compilador, la función se convierte en bytecode en tiempo de compilación, y el bytecode (más bien, la dirección del punto de entrada) se asocia en tiempo de ejecución con el entorno actual.

La composición de la función puede confiar en la función anónima. Cuando un compilador encuentra un operador de composición de función f . g, crea una función anónima que llama a los dos argumentos f y g, pasando el resultado de uno como argumento al otro.

Las mónadas se pueden implementar en idiomas OO, simplemente no son tan necesarias como en los lenguajes funcionales puros.Las mónadas de E/S no son demasiado especiales, solo se basan en el hecho de que la plataforma subyacente permite efectos secundarios.

Answer 6

La mayor diferencia que se le viene a la mente es que los lenguajes funcionales tienden a diseñarse para que el código fuente sea desugared a un lenguaje intermedio matemáticamente simple y potente. Este lenguaje generalmente contiene lambda, llamadas a funciones, if/else, tipos de máquina, algo así como let, y no mucho más. El código transformado está profundamente anidado, prolijo y no es realistamente legible por el ser humano. La sintaxis de la superficie se descarta.

Un compilador para un lenguaje como este tiene que hacer algunas incrustaciones y algunas optimizaciones de cierre para producir código decente. (Para mí, estas optimizaciones de cierre de línea de base parecen no triviales - análisis de escape y demás - pero podría ser simplemente una falta de familiaridad).

Answer 7

@outis: Si bien el lenguaje puede admitirlos, los cierres entran en conflicto con el concepto matemático de un funcionan de la misma manera que los efectos secundarios: le permiten obtener resultados diferentes a partir de los mismos argumentos. Eso hace que los cierres sean de procedimiento, más que funcionales.

Dicho esto, existen argumentos de eficiencia que favorecen los cierres sobre los globales (especialmente en el contexto de la implementación del compilador). [Pero conozco idiomas funcionales que no proporcionan cierres directamente, aunque se puede implementar "trabajo similar".]

(Sin embargo, el currying es similar a los cierres y no sufre este conflicto, y de hecho está presente de forma rutinaria en idiomas funcionales.)

De todos modos, en mi opinión, los lenguajes de programación funcional son lenguajes que hacen grandes esfuerzos para que el cálculo sea representable como si fueran funciones matemáticas. Esto significa que las optimizaciones están sesgadas en la optimización de funciones.

Hipotéticamente, al menos, los lenguajes funcionales permiten que la máquina trabaje en abstracciones más profundas de lo que sería útil para un enfoque puramente de procedimiento.