2010-02-12 26 views
6

Estoy trabajando en una herramienta que realizará algunas transformaciones simples en programas (como método de extracción). Para hacer esto, tendré que realizar los primeros pasos de compilación (tokenizar, analizar y posiblemente construir una tabla de símbolos). Comenzaré con C y luego extenderé esto para admitir varios idiomas.La mejor manera de tokenizar y analizar lenguajes de programación en mi aplicación

Mi pregunta es, ¿cuál es la mejor manera de realizar estos pasos:

1.) no reinventar la rueda. Claramente, no quiero escribir especificaciones de Flex/Bison a mano. ¿Acabo de obtener especificaciones preexistentes y trabajo desde allí? ¿Antlr es el camino a seguir aquí?

2.) Es extensible a varios idiomas. Obviamente, el lexing/parsing será diferente para todos, pero me gustaría una solución que pueda extender fácilmente a otros idiomas. Al menos un conjunto de tecnologías que lo haría manejable.

Por cierto, estoy usando C para escribir mis aplicaciones

Si alguien tiene alguna idea que sería genial! ¡Gracias!

Respuesta

1

No se ha especificado un idioma, así que voy a recomendar esta pequeña joya que encontré el otro día:

http://irony.codeplex.com/

Es super fácil de usar, e incluso ha gramáticas pre-construido para varios idiomas (C# incluso). También hay pyparsing (http://pyparsing.wikispaces.com/) si quiere usar Python como su idioma de origen.

+0

Ha, perdón por eso. Estoy usando C. – ChrisDiRulli

-2

Una puerta para pasar es Eclipse. Tiene un análisis sintáctico, que incluye análisis tolerante a errores, para una variedad de idiomas. Eclipse tiene una modularidad interna que le permite explotar esta funcionalidad sin tocar el IDE.

+0

que parece una forma demasiado compleja de hacerlo. Usa un ide para construir una utilidad? –

+0

No conozco la base de código de Eclipse, pero si puede extraer fácilmente el código de análisis y código en Java, podría ser una gran idea. Si está codificando en C, también puede ver las interfaces de gcc para diferentes idiomas, ya que las personas de gcc ya se esfuerzan por generar una representación común de los analizadores para todo tipo de idiomas para que puedan usar las mismas rutinas de generación de código para idiomas diferentes. Pero ten en cuenta que la base de códigos es enorme y que es más fácil simplemente rodar tu propio analizador. – ahe

2

Dado que va a utilizar gramáticas ya escritas y expresiones regulares, la elección de la herramienta no es suficiente.

Usted puede ir con flex/bisontes y encontrará muchas gramáticas ya escrito. De lo contrario, puede ir con ANTLR que debería funcionar en C, C++ y Java sin problemas y hacer lo mismo también por ello.

Usted no habló sobre qué idioma va a utilizar para este trabajo, por lo que no es tan fácil sugerir un mejor enfoque.

Piense en el hecho de que cada idioma tiene sus propias características, por ejemplo, la tabla de símbolos se construye de una manera diferente en Ruby en comparación con C++. Esto se debe a que puede tener declaraciones más estrictas o más flexibles, etc., por lo que debe pensar bien qué va a necesitar (y también puede explicarlo en su pregunta, para que pueda brindarle una mejor ayuda).

de sus dos fases, puedo decir que

  • Tokenización es bastante simple, no requiere estructuras diferentes para cada idioma y se puede ampliar fácilmente para soportar una gran cantidad de lenguajes de programación ..

  • El análisis puede ser más difícil. Debe crear un Árbol de sintaxis abstracta del programa y luego hacer lo que desee en él. Si te gusta hacer el estilo OOP deberás usar una clase para cada tipo de nodo, pero los tipos de nodo pueden cambiar entre idiomas porque son estructuralmente diferentes, por lo que hacer algo general y extenderlo fácilmente a otro idioma es bastante complicado.

Para este punto, ANTLR gana con Flex y Bison porque ofrece una generación automática de AST (si mal no recuerdo).

La principal diferencia entre los compiladores de estos dos de compilador es el hecho de que antlr utiliza un LL (k) analizador (es decir de arriba hacia abajo), mientras que Bison utiliza un LALR (1) que es de abajo hacia arriba, pero si Usas gramáticas ya escritas que no deberían ser tan difíciles.

Un consejo personal: escribí muchos intérpretes o compiladores pero nunca comencé con un lenguaje completo. C sintaxis es realmente grande así que tal vez deba comenzar desde un subconjunto, luego vea qué puede hacer con tokens y AST y luego extiéndalo para soportar la sintaxis completa.

+0

Desafortunadamente antlr no genera ASTs automáticamente. Tienes que escribir reglas para eso, de lo contrario obtendrás una lista enlazada de tokens como AST. Aparte de eso, realmente desea escribir reglas ya que al menos para cada lenguaje no trivial desea tener nodos abstractos en su AST. Para dar un ejemplo si analiza un nombre de clase FQ Java como 'java.util.List', no desea obtener simplemente los nodos de identificación 'java', 'util', 'List' y dos nodos para los tokens DOT en entre pero desea tener un nodo abstracto 'CLASSNAME' arriba para que solo al mirar su AST sepa qué significan esos tokens. – ahe

2

¿En qué idioma escribe su programa?

Iría con antlr (y de hecho voy a analizar Java). Es compatible con una gran cantidad de idiomas y también tiene muchas gramáticas de ejemplo que obtienes gratis http://www.antlr.org/grammar/list. Desafortunadamente no tienen que ser perfectos (la gramática Java no tiene reglas AST) pero te dan un buen comienzo y supongo que la comunidad es bastante grande para un generador de analizadores sintácticos.

Lo mejor con antlr aparte de los muchos objetivos del lenguaje es que LL (*) combinado con los predicados soportados por antlr es muy poderoso, fácil de entender y los analizadores generados también lo son.

Con "extensible a varios idiomas", supongo que se refiere a varios idiomas de origen. Esto no es fácil, pero supongo que puede tener cierto éxito al traducirlos a AST que tienen tantos símbolos comunes como sea posible y escribir un andador de árbol general que pueda manejar las diferencias en esos idiomas. Pero esto podría ser bastante difícil.

Tenga en cuenta, sin embargo, que la documentación en línea solo es válida una vez que haya leído el libro oficial de antlr y comprenda LL (*) y los predicados semánticos y sintácticos.

+0

su ANTLR URL es 404. –

Cuestiones relacionadas