¿Que meter en un generador de compiladores?

Pues eso, antes de que se me olvide hay que recordar que en el compilador hay que ver:

- El uso de XML para definir o especificar el compilador
- El uso de anotaciones para definir o especificar el compilador
- El uso de AOP para constuir las acciones semánticas del compilador
- Hay que usar el patrón observador jerarquico y compararlo con AOP.
- Usar la separación entre la API pública del AST formada por interfaces y las clases de implementación. Sobre todo por la herencia múltiple y porque no se quieren publicar a las herramientas que hagan uso de él ciertos métodos usados internamente.
- ¿Cómo representamos en el AST los errores sintácticos?. ¿Haciendo objetos dummy que elevan RuntimeExceptions cuando se crean como resultado de una recuperación de errores?
- ¿Cómo usar gclib para crear visitadores en tiempo de ejecución de forma eficiente?
- Hay que tener un formato para serializar un AST con los atributos establecidos en disco.
- Hay que ver cómo reconocer bajo demanda el fuente para que no esté siempre en memoria si no es necesario. Puesto que el AST estará formado por objetos normales, habrá que usar reflection o algo. La idea es que en vez de modificar una clase del AST el desarrollador creará una clase con una referencia a la del AST. De forma que sea posible dejar en memoria estos objetos y serializar el AST.
- Hay que usar un nuevo tipo de visitadores que permitan ejecutar acciones para los objetos de determinadas clases. Pero no recorrer el árbol completamente, si no sólo los objetos de las clases "marcadas". Por ejemplo, realizar un fase de búsqueda previa y luego ejecutar las acciones semánticas. El objetivo es mantener en caché la lista de objetos para que las acciones posteriores se realicen más rápidamente.
- Realizar el patrón observer jerarquico sólo para algunas clases. De forma que no tiene porque realizarse en todos los objetos.
- Para que la gente sepa como usar la API del AST. Se debe proporcionar una herramienta que transforme un código válido en el lenguaje de programación en un código Java que permita construir ese mismo código fuente usando la API, eso ayudará mucho a comprender la API.
- Hay que tener el soporte de ficheros y directorios en la propia API generada por el compilador, de forma que los visitadores puedan recorrer estos elementos como objetos del AST.
- Por supuesto, los ficheros se pueden mapear a buffers de texto, es decir a componentes de texto Swing.
- Compilación incremental
- Generación de pretty-printers
- Modificar el orden de recorrido de los visitadores de una forma más ordenada. Por ejemplo, si en la lista de miembros aparecen intercalados métodos, atributos y otros tipos, puede ser interesante recorrer todos los miembros de un tipo todos a la vez. Además, este tipo de ordenaciones deberán poder ser accedidas a travás de métodos a listas de esos tipos. De una forma automática.
- Soporte para una sintaxis que permita especificar consultas sobre el código. Algo así como patrones de código que se "acojen" a códigos específicos. Es decir, crear una API de búsqueda genérica, independiente del lenguaje.
- Objetos que no están en el fuente pero que son "puestos automáticamente" por el compilador, por ejemplo, el constructor sin parámentros, la llamada al constuctor de la clase padre, el import de java.lang, etc... Es decir, hay que poder configurar en el visitador si se recorren estos objetos o no, porque no están realmente en el código. La clase Node, debe disponer de un método para saber si ese objeto es ficticio o no.
- Dejar la gramática disponible en runtime (si es necesrio). Esto podría permitir metaprogramación pero más semántica, más orientada a la gramática. Por ejemplo para crear gráficos más simples, vistas en modo árbol, etc... Hay que ver cual es la mejor forma de representar esta gramática.
- Hay que hacer que los errores sintácticos sean (en la medida de los posible) cercanos a la especificación de alto nivel por interfaces. Es decir, hay que usar nombres coherentes para los interfaces, y los errores tienen que referenciarlos a ellos, no a la gramática.
- El sistema de proporcionar formas para la depuración de la gramática. De alguna forma sencilla y estándar el usuario debe poder ver el progreso de reconocimiento. Por ejemplo proporcionar una miniherramienta tipo ENVIDO pero para depurar la gramática.
- Se deben proporcionar formas de reconocer partes de la gramática aisladas. Creando talblas nuevas (poco eficiente pero rápido de desarrollar) o bien de forma integrada al analizador LALR.
- Investigar las formas de representar un AST "ambiguo". Es decir, un AST que realmente no es un árbol si no muchos árboles en ciertas partes. Se podría mantener en memoria la primera alternativa de las posibles y luego ir cambiándolas bajo demanda, para probar su viabilidad con métodos semánticos.