Programación extensible

Como es habitual, un lenguaje extensible consta de un lenguaje base que proporciona funcionalidades informáticas básicas y un metalenguaje capaz de modificar dicho lenguaje base. Un programa, a su vez, consta de modificaciones del metalenguaje y código escrito en el lenguaje base modificado.

La técnica de extensión de 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 del lenguaje Lisp se mantuvo separada de la comunidad de lenguajes extensibles, 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. ... Esto se puede comprobar 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 extensible.

Standish describió tres clases de extensión del lenguaje, a las que denominó paráfrasis , ortófrasis y metáfrasis (de lo contrario, paráfrasis y metáfrasis serían términos de traducción ).

• La paráfrasis define una funcionalidad mostrando cómo intercambiarla por algo previamente definido (o por definir). Como ejemplos, menciona definiciones de macros, definiciones de procedimientos ordinarios, extensiones gramaticales, definiciones de datos, definiciones de operadores y extensiones de estructuras de control.
• La ortofrase añade características a un lenguaje que no se podían lograr con el lenguaje base, como por ejemplo, añadir un sistema de entrada/salida (E/S) a un lenguaje base que antes carecía de primitivas de E/S. Las extensiones deben entenderse como ortofrase relativa a un lenguaje base dado, ya que una característica no definida en términos del lenguaje base debe definirse en términos de otro lenguaje. Esto corresponde a la noción moderna de complementos .
• La metáfora modifica las reglas de interpretación utilizadas para expresiones preexistentes. Esto se corresponde con la noción moderna de programación reflexiva (reflexión).

Standish atribuyó el fracaso del movimiento de extensibilidad a la dificultad de programar extensiones sucesivas. Un programador podría crear una primera capa de macros sobre un lenguaje base. Si luego se crea una segunda capa de macros sobre esta, cualquier programador posterior debe conocer a fondo tanto el lenguaje base como la primera capa. Una tercera capa requeriría familiaridad con el lenguaje base y con las dos primeras, y así sucesivamente. Proteger al programador de los detalles de bajo nivel es la intención del movimiento de abstracción que reemplazó al de extensibilidad.

A pesar de la presentación inicial de Simula como extensible, en 1975, el estudio de Standish no parece haber incluido en la práctica las tecnologías más recientes basadas en la abstracción (aunque utilizó una definición muy general de extensibilidad que técnicamente podría haberlas incluido). Una historia de la abstracción de programación de 1978, desde la invención de la computadora hasta entonces, no mencionaba las macros y no daba ninguna pista de que el movimiento de 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 aparición de las macros higiénicas ), al otorgándoseles el seudónimo de abstracciones sintácticas . ^{[ 10 ]}

Esto simplemente significa que el o los lenguajes 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 o los lenguajes fuente. Los lenguajes que permiten la adición de construcciones con sintaxis definida por el usuario incluyen Rocq , ^{[ 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. Debe ser posible agregar otras nuevas.

En la programación extensible, un compilador no es un programa monolítico que convierte el código fuente en código binario ejecutable. El compilador debe ser extensible hasta el punto de ser, en realidad, una colección de complementos que facilitan la traducción del lenguaje fuente a cualquier formato . Por ejemplo, un compilador extensible admite la generación de código objeto, documentación del código, código fuente reformateado o cualquier otro resultado deseado. La arquitectura del compilador debe permitir a sus usuarios acceder al proceso de compilación y ofrecer tareas de procesamiento alternativas en cada paso razonable del mismo.

Para la simple tarea de traducir el código fuente a algo que pueda ejecutarse en una computadora, un compilador extensible debería:

• Utiliza una arquitectura de complementos o componentes para casi todos los aspectos de su funcionamiento.
• determinar qué idioma o variante de idioma se está compilando y localizar el complemento apropiado para reconocer y validar ese idioma.
• utilizar especificaciones de lenguaje formal para validar sintáctica y estructuralmente lenguajes fuente arbitrarios
• ayudar con la validación semántica de lenguajes fuente arbitrarios invocando un complemento de validación apropiado.
• Permite a los usuarios seleccionar entre diferentes tipos de generadores de código para que el ejecutable resultante pueda estar dirigido a diferentes procesadores, sistemas operativos, máquinas virtuales u otros entornos de ejecución.
• proporcionar facilidades para la generación de errores y extensiones de los mismos
• permitir nuevos tipos de nodos en el árbol de sintaxis abstracta (AST),
• permitir nuevos valores en los nodos del AST,
• permitir nuevos tipos de aristas entre nodos,
• admitir la transformación del AST de entrada, o partes del mismo, mediante algún "paso" externo.
• admitir la traducción del AST de entrada, o partes del mismo, a otra forma mediante algún "paso" externo.
• Ayudan con el flujo de información entre los pasos internos y externos, ya que transforman y traducen el AST en nuevos AST u otras representaciones.

En tiempo de ejecución, los sistemas de programación extensibles deben permitir que los lenguajes amplíen el conjunto de operaciones que admiten. Por ejemplo, si el sistema utiliza un intérprete de código de bytes , debe permitir la definición de nuevos valores de código de bytes. Al igual que con la sintaxis extensible, es aceptable que exista un conjunto (relativamente pequeño) de operaciones fundamentales o intrínsecas que sean inmutables. Sin embargo, debe ser posible sobrecargar o ampliar dichas operaciones intrínsecas para admitir comportamientos nuevos o adicionales.

Los sistemas de programación extensibles deben considerar los programas como datos que se procesan. Dichos programas deben carecer por completo 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, compatible con el compilador extensible, que traduce los datos del programa a formatos más adecuados para su visualización o edición. Naturalmente, esta traducción debe ser 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 en lenguaje fuente sean la edición, la visualización y la traducción a código máquina. El procesamiento arbitrario de programas se facilita al desacoplar la entrada en lenguaje fuente de las especificaciones sobre cómo debe procesarse (formatearse, almacenarse, visualizarse, editarse, etc.).

Los sistemas de programación extensibles deben admitir la depuración de programas utilizando las construcciones del lenguaje fuente original, independientemente de las extensiones o transformaciones que haya sufrido el programa para hacerlo ejecutable. En particular, no se puede asumir que la única forma de mostrar datos en tiempo de ejecución sea mediante 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 de negocio o flujo de trabajo , el depurador debe poder mostrar dicha estructura de datos como un diagrama de Ishikawa u otro formato proporcionado por un complemento.

1. Artículo de Greg Wilson en la cola de ACM
2. Discusión en Slashdot
3. Lenguajes extensibles modernos archivados el 12 de junio de 2011 en la Wayback Machine – Un artículo de Daniel Zingaro

1. MetaL : una implementación de motor de compilación de programación extensible
2. XPS – Sistema de Programación Extensible (en desarrollo)
3. MPS – Sistema de metaprogramación de JetBrains

1. OpenZz
2. xtc – C extensible
3. Escritura en inglés
4. Macros de Nemerle
5. Macros sintácticas Boo
6. Compilador de formato intermedio de la Universidad de Stanford
7. Seed7 – El lenguaje de programación extensible
8. Katahdin : un lenguaje con sintaxis y semántica mutables en tiempo de ejecución.
9. π – un lenguaje con sintaxis extensible, implementado mediante un analizador sintáctico de Earley.