En informática , la programación puramente funcional suele designar un paradigma de programación —un estilo de construcción de la estructura y los elementos de los programas de computadora— que trata todo cálculo como la evaluación de funciones matemáticas .
El estado del programa y los objetos mutables generalmente se modelan con lógica temporal , como variables explícitas que representan el estado del programa en cada paso de la ejecución de un programa: un estado variable se pasa como parámetro de entrada de una función transformadora de estado, que devuelve el estado actualizado como parte de su valor de retorno. Este estilo maneja cambios de estado sin perder la transparencia referencial de las expresiones del programa.
La programación puramente funcional consiste en asegurar que las funciones, dentro del paradigma funcional , dependerán únicamente de sus argumentos, independientemente de cualquier estado global o local. Una subrutina funcional pura sólo tiene visibilidad de los cambios de estado representados por las variables de estado incluidas en su alcance.
La diferencia exacta entre programación funcional pura e impura es motivo de controversia. La definición de pureza propuesta por Sabry es que todas las estrategias de evaluación comunes (llamada por nombre, llamada por valor y llamada por necesidad) producen el mismo resultado, ignorando las estrategias que cometen errores o divergen. [1]
Generalmente se dice que un programa es funcional cuando utiliza algunos conceptos de programación funcional , como funciones de primera clase y funciones de orden superior . [2] Sin embargo, una función de primera clase no tiene por qué ser puramente funcional, ya que puede utilizar técnicas del paradigma imperativo , como matrices o métodos de entrada/salida que utilizan celdas mutables, que actualizan su estado como efectos secundarios. De hecho, los primeros lenguajes de programación citados como funcionales, IPL y Lisp , [3] [4] son ambos lenguajes funcionales "impuros" según la definición de Sabry.
Cada estrategia de evaluación que termina en un programa puramente funcional arroja el mismo resultado. En particular, garantiza que el programador no tenga que considerar en qué orden se evalúan los programas, ya que una evaluación entusiasta arrojará el mismo resultado que una evaluación diferida . Sin embargo, todavía es posible que una evaluación entusiasta no termine mientras se detiene la evaluación perezosa del mismo programa. Una ventaja de esto es que la evaluación diferida se puede implementar mucho más fácilmente; Como todas las expresiones devolverán el mismo resultado en cualquier momento (independientemente del estado del programa), su evaluación puede retrasarse tanto como sea necesario.
En un lenguaje puramente funcional, las únicas dependencias entre los cálculos son las dependencias de datos y los cálculos son deterministas. Por lo tanto, para programar en paralelo, el programador sólo necesita especificar las piezas que deben calcularse en paralelo, y el tiempo de ejecución puede manejar todos los demás detalles, como distribuir tareas a los procesadores, gestionar la sincronización y la comunicación y recolectar basura en paralelo. Este estilo de programación evita problemas comunes como condiciones de carrera y puntos muertos, pero tiene menos control que un lenguaje imperativo. [5]
Para garantizar una aceleración, la granularidad de las tareas debe elegirse cuidadosamente para que no sea ni demasiado grande ni demasiado pequeña. En teoría, es posible utilizar perfiles en tiempo de ejecución y análisis en tiempo de compilación para juzgar si la introducción del paralelismo acelerará el programa y, por lo tanto, paralelizará automáticamente programas puramente funcionales. En la práctica, esto no ha tenido mucho éxito y la paralelización totalmente automática es una quimera. [5]
Las estructuras de datos puramente funcionales son persistentes . Se requiere persistencia para la programación funcional; sin él, el mismo cálculo podría arrojar resultados diferentes. La programación funcional puede utilizar estructuras de datos persistentes no puramente funcionales , mientras que esas estructuras de datos no pueden utilizarse en programas puramente funcionales.
Las estructuras de datos puramente funcionales a menudo se representan de forma diferente a sus contrapartes imperativas . [6] Por ejemplo, la matriz con acceso y actualización en tiempo constante es un componente básico de la mayoría de los lenguajes imperativos y muchas estructuras de datos imperativas, como la tabla hash y el montón binario , se basan en matrices. Los arrays pueden ser sustituidos por mapa o lista de acceso aleatorio, que admite implementación puramente funcional, pero el tiempo de acceso y actualización es logarítmico . Por lo tanto, las estructuras de datos puramente funcionales se pueden utilizar en lenguajes que no son funcionales, pero pueden no ser la herramienta más eficiente disponible, especialmente si no se requiere persistencia.
En general, la conversión de un programa imperativo a uno puramente funcional también requiere garantizar que las estructuras anteriormente mutables ahora sean devueltas explícitamente por funciones que las actualizan, una estructura de programa llamada estilo de paso de almacenamiento .
Un lenguaje puramente funcional es un lenguaje que sólo admite programación puramente funcional. Sin embargo, los programas puramente funcionales pueden escribirse en lenguajes que no sean puramente funcionales.