ANTLR vs. Happy vs. otros generadores de analizador

Question

Quiero escribir un traductor entre dos idiomas, y después de leer un poco en Internet decidí usar ANTLR. Tuve que aprenderlo desde cero, pero además de algunos problemas para eliminar la recursividad a la izquierda, todo salió bien hasta ahora.

Sin embargo, hoy un tipo me dijo que echara un vistazo a Happy, un generador de analizadores basado en Haskell. No tengo conocimiento de Haskell, así que podría usar algunos consejos, si Happy es de hecho mejor que ANTLR y si vale la pena aprenderlo.

Específicamente, lo que me preocupa es que mi traductor debe admitir la sustitución de macros, que aún no tengo idea de cómo hacerlo en ANTLR. Tal vez en Feliz esto es más fácil de hacer?

O si crees que otros generadores de analizadores son incluso mejores, me alegraría saber de ellos.

Answer 1

La gente sigue creyendo que si solo obtienen un analizador sintáctico, lo tienen hecho al crear herramientas de lenguaje. Eso está mal. Parsers te lleva a las estribaciones del Himalaya luego necesitas empezar a escalar en serio.

Si desea soporte de resistencia industrial para la construcción de traductores de idiomas, vea nuestro DMS Software Reengineering Toolkit. DMS ofrece

• lexers de tipo Unicode
• completos programas de análisis independientes del contexto (recursión por la izquierda, no hay problema! Lookahead arbitraria, no hay problema. Gramáticas ambiguas, no hay problema)
• frontal completo termine para C, C#, COBOL, Java, C++, JavaScript, ... (incluyendo pre-procesadores completos para C y C++)
• construcción automática de AST
• apoyo para la construcción de tablas de símbolos con reglas de alcance arbitrarias
• attrib Evaluación gramática UTE, para construir analizadores que aprovechan la estructura de árbol
• apoyo para el control y el análisis de flujo de datos (como realización así de este por completo C, Java y COBOL),
• -fuente a fuente transformaciones usando la sintaxis de la fuente y el idioma de destino
• AST a prettyPrinting código fuente, para reproducir texto en el idioma de destino

en cuanto a la petición de la OP para manejar macros: nuestra C, COBOL y C++ extremos delanteros manejar su respectivo procesamiento previo idioma mediante: a) el método tradicional de expansión completa ob) no expansión (cuando sea práctico) para permitir el cambio posterior al análisis mación de las macros. Si bien DMS como base no implementa específicamente macroprocesamiento, puede admitir la construcción y transformación de los mismos.

Como ejemplo de un traductor construido con DMS, consulte la discusión de converting JOVIAL to C for the B-2 bomber. Esta es una traducción del 100% para> 1 MSLOC del código de tiempo real . [Puede que te divierta saber que nunca nos permitieron ver el programa real siendo traducido (alto secreto).]. Y sí, JOVIAL tiene un preprocesador, y sí, hemos traducido la mayoría de las macros JOVIAL a versiones C equivalentes.

[Haskell es un lenguaje de programación genial, pero no hace nada como esto por sí mismo. Esto no se trata de lo que se puede expresar en el idioma.Sus cerca de averiguar lo que se requiere de maquinaria para apoyar la tarea de los programas de manipulación, y años-hombre de gasto 100 construirlo.]