En informática , la programación extensible es un estilo de programación informática que se centra en los mecanismos para extender el lenguaje de programación , el compilador y el sistema de ejecución (entorno). Los lenguajes de programación extensibles, que respaldan este estilo de programación, fueron un área de trabajo activa en la década de 1960, pero el movimiento quedó marginado en la década de 1970. [1] La programación extensible se ha convertido en un tema de renovado interés en el siglo XXI. [2]
El primer artículo que generalmente [1] [3] se asocia con el movimiento de lenguajes de programación extensibles es el artículo de 1960 de M. Douglas McIlroy sobre macros para lenguajes de programación de alto nivel . [4] Otra descripción temprana del principio de extensibilidad aparece en el artículo de 1960 de Brooker y Morris sobre el compilador-compilador . [5] El apogeo del movimiento estuvo marcado por dos simposios académicos, en 1969 y 1971. [6] [7] En 1975, un artículo de investigación sobre el movimiento escrito por Thomas A. Standish [1] era esencialmente una autopsia. El Forth fue una excepción, pero pasó esencialmente desapercibido.
Tal como se suele concebir, un lenguaje extensible consta de un lenguaje base que proporciona funciones informáticas elementales y un metalenguaje capaz de modificar el lenguaje base. Por tanto, un programa consta de modificaciones del metalenguaje y código en el lenguaje base modificado.
La técnica de extensión del lenguaje más destacada utilizada en el movimiento fue la definición de macros. La modificación gramatical también estuvo estrechamente asociada con el movimiento, lo que dio como resultado el desarrollo final de los formalismos gramaticales adaptativos . La comunidad del lenguaje Lisp permaneció separada de la comunidad del lenguaje extensible, aparentemente porque, como observó un investigador,
cualquier lenguaje de programación en el que los programas y los datos sean esencialmente intercambiables puede considerarse un lenguaje extensible [sic]. ... esto se puede ver muy fácilmente a partir del hecho de que Lisp se ha utilizado como un lenguaje extensible durante años. [8]
En la conferencia de 1969, Simula se presentó como un lenguaje extensible.
Standish describió tres clases de extensión del lenguaje, que llamó paráfrasis , ortofrasis y metáfrasis (de lo contrario, paráfrasis y metáfrasis son términos de traducción ).
Standish atribuyó el fracaso del movimiento de extensibilidad a la dificultad de programar extensiones sucesivas. Un programador podría construir un primer shell de macros alrededor de un lenguaje base. Luego, si se construye un segundo shell de macros alrededor de ese, cualquier programador posterior debe estar íntimamente familiarizado tanto con el lenguaje base como con el primer shell. Un tercer shell requeriría familiaridad con el lenguaje base y tanto con el primer como con el segundo shell, y así sucesivamente. Proteger a un programador de los detalles de nivel inferior es la intención del movimiento de abstracción que suplantó al movimiento de extensibilidad.
A pesar de la presentación anterior de Simula como extensible, en 1975, el estudio de Standish no parece haber incluido en la práctica las tecnologías más nuevas basadas en abstracciones (aunque utilizó una definición muy general de extensibilidad que técnicamente podría haberlas incluido). Una historia de la abstracción de la programación de 1978 desde la invención de la computadora hasta entonces, no hizo mención de las macros y no dio ninguna pista de que el movimiento de los lenguajes extensibles hubiera ocurrido alguna vez. [9] Las macros fueron admitidas tentativamente en el movimiento de abstracción a fines de la década de 1980 (quizás debido al advenimiento de las macros higiénicas ), al otorgárseles el seudónimo de abstracciones sintácticas . [10]
En el sentido moderno, un sistema que admita programación extensible proporcionará todas las características descritas a continuación [ cita requerida ] .
Esto simplemente significa que el lenguaje fuente que se va a compilar no debe ser cerrado, fijo o estático. Debe ser posible agregar nuevas palabras clave, conceptos y estructuras al lenguaje fuente. Los lenguajes que permiten la adición de construcciones con sintaxis definida por el usuario incluyen Coq , [11] Racket , Camlp4 , OpenC++, Seed7 , [12] Red , Rebol y Felix. Si bien es aceptable que algunas características fundamentales e intrínsecas del lenguaje sean inmutables, el sistema no debe depender únicamente de esas características del lenguaje. Debe ser posible agregar otras nuevas.
En la programación extensible, un compilador no es un programa monolítico que convierte la entrada de código fuente en una salida ejecutable binaria. El compilador en sí debe ser extensible hasta el punto de que sea realmente una colección de complementos que ayudan con la traducción de la entrada del lenguaje fuente a cualquier cosa . Por ejemplo, un compilador extensible admitirá la generación de código objeto, documentación de código, código fuente reformateado o cualquier otra salida deseada. La arquitectura del compilador debe permitir a sus usuarios "entrar" en el proceso de compilación y proporcionar tareas de procesamiento alternativas en cada paso razonable del proceso de compilación.
Sólo para la tarea de traducir el código fuente en algo que pueda ejecutarse en una computadora, un compilador extensible debería:
En tiempo de ejecución, los sistemas de programación extensible deben permitir que los lenguajes amplíen el conjunto de operaciones que permiten. Por ejemplo, si el sistema utiliza un intérprete de código de bytes , debe permitir que se definan nuevos valores de código de bytes. Al igual que con la sintaxis extensible, es aceptable que exista un conjunto (pequeño) de operaciones fundamentales o intrínsecas que sean inmutables. Sin embargo, debe ser posible sobrecargar o aumentar esas operaciones intrínsecas para que se pueda admitir un comportamiento nuevo o adicional.
Los sistemas de programación extensible deben considerar los programas como datos que deben procesarse. Dichos programas deben estar completamente desprovistos de cualquier tipo de información de formato. La visualización y edición de los programas para los usuarios debe ser una función de traducción, apoyada por el compilador extensible, que traduzca los datos del programa a formatos más adecuados para su visualización o edición. Naturalmente, esta debe ser una traducción bidireccional. Esto es importante porque debe ser posible procesar fácilmente los programas extensibles de diversas maneras . Es inaceptable que los únicos usos de la entrada del lenguaje fuente sean la edición, la visualización y la traducción a código de máquina. El procesamiento arbitrario de los programas se facilita desvinculando la entrada fuente de las especificaciones sobre cómo debe procesarse (formatearse, almacenarse, visualizarse, editarse, etc.).
Los sistemas de programación extensible deben permitir la depuración de programas utilizando las estructuras del lenguaje fuente original, independientemente de las extensiones o transformaciones que haya sufrido el programa para hacerlo ejecutable. En particular, no se puede suponer que la única forma de mostrar datos en tiempo de ejecución sea en estructuras o matrices . El depurador, o más correctamente, el "inspector de programas", debe permitir la visualización de datos en tiempo de ejecución en formatos adecuados para el lenguaje fuente. Por ejemplo, si el lenguaje admite una estructura de datos para un proceso empresarial o un flujo de trabajo , el depurador debe poder mostrar esa estructura de datos como un diagrama de espina de pescado u otro formato proporcionado por un complemento.