Programación extensible es un término utilizado en informática para describir un estilo de programación informática que se centra en mecanismos para ampliar el lenguaje de programación , el compilador y el entorno de ejecución . Los lenguajes de programación extensibles, que apoyaban 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 generalmente [1] [3] asociado 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 nivel superior. [4] Otra descripción temprana del principio de extensibilidad aparece en el artículo de Brooker y Morris de 1960 sobre el Compilador-Compilador . [5] El pico del movimiento estuvo marcado por dos simposios académicos, en 1969 y 1971. [6] [7] En 1975, un artículo de estudio sobre el movimiento escrito por Thomas A. Standish [1] era esencialmente una autopsia. El lenguaje de programación Forth fue una excepción, pero pasó prácticamente desapercibido.
Como se suele imaginar, un lenguaje de programación extensible constaba de un lenguaje base que proporcionaba funciones informáticas elementales y un metalenguaje capaz de modificar el lenguaje base. Luego, un programa consistía en 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 macrodefinición. La modificación gramatical también estuvo estrechamente asociada con el movimiento, lo que resultó en el eventual desarrollo de formalismos gramaticales adaptativos . La comunidad lingüística Lisp permaneció separada de la comunidad lingüística 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 por el hecho de que Lisp se ha utilizado como lenguaje extensible durante años. [8]
En la conferencia de 1969, Simula se presentó como un lenguaje de programación extensible.
Standish describió tres clases de extensión del lenguaje, a las que llamó paráfrasis , ortofrase y metafrase (de lo contrario, paráfrasis y metafrase son términos de traducción ).
Standish atribuyó el fracaso del movimiento de extensibilidad a la dificultad de programar extensiones sucesivas. Un programador común podría construir un único shell de macros alrededor de un lenguaje base, pero si se fuera a construir un segundo shell de macros alrededor de ese, el programador tendría que estar íntimamente familiarizado tanto con el lenguaje base como con el primer shell; un tercer caparazón requeriría familiaridad con la base y tanto con el primer como con el segundo caparazón; etcétera. (Tenga en cuenta que proteger al 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 la abstracción (aunque utilizó una definición muy general de extensibilidad que técnicamente podría haberlas incluido). Una historia de 1978 sobre la abstracción de la programación desde la invención de la computadora hasta el (entonces) presente no hizo mención de las macros y no dio ningún indicio 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 finales de la década de 1980 (quizás debido a la llegada de las macros higiénicas ), al concederles el seudónimo de abstracciones sintácticas . [10]
En el sentido moderno, un sistema que admita programación extensible proporcionará todas las características que se describen a continuación [ cita necesaria ] .
Esto simplemente significa que los idiomas fuente que se van a compilar no deben ser cerrados, fijos ni estáticos. Debe ser posible agregar nuevas palabras clave, conceptos y estructuras al idioma(s) de origen. 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 otros nuevos.
En programación extensible, un compilador no es un programa monolítico que convierte la entrada del código fuente en una salida ejecutable binaria. El compilador en sí debe ser extensible hasta el punto de que sea en realidad una colección de complementos que ayudan con la traducción de la entrada del idioma 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 otro resultado deseado. 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 a algo que pueda ejecutarse en una computadora, un compilador extensible debería:
En tiempo de ejecución, los sistemas de programación extensibles deben permitir que los lenguajes extiendan 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 haya algún 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 soportar un comportamiento nuevo o adicional.
Los sistemas de programación extensibles deberían considerar los programas como datos a procesar. Esos programas deberían estar completamente desprovistos de cualquier tipo de información de formato. La visualización y edición de programas para los usuarios debe ser una función de traducción, respaldada por el compilador extensible, que traduce los datos del programa a formas más adecuadas para su visualización o edición. Naturalmente, esta debería ser una traducción bidireccional. Esto es importante porque debe ser posible procesar fácilmente programas extensibles de diversas formas. Es inaceptable que los únicos usos de la entrada del idioma fuente sean la edición, visualización y traducción a código de máquina. El procesamiento arbitrario de programas se facilita al desacoplar la entrada fuente de las especificaciones de cómo debe procesarse (formateado, almacenado, mostrado, editado, etc.).
Los sistemas de programación extensibles deben soportar la depuración de programas utilizando las construcciones del lenguaje fuente original, independientemente de las extensiones o transformaciones que haya experimentado el programa para hacerlo ejecutable. En particular, no se puede asumir 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 al idioma fuente. Por ejemplo, si el lenguaje admite una estructura de datos para un proceso de negocio o flujo de trabajo , el depurador debe poder mostrar esa estructura de datos como un gráfico de espina de pescado u otra forma proporcionada por un complemento.