Objetivos
Para este proyecto se espera:
- Que el alumno construya un AST en base a un parser para el lenguaje Decaf.
- Que el alumno ponga en práctica lo visto en clase sobre ASTs, utilizando herramientas como ANTLR.
Descripción
AST
Debe escribir un AST en base al arbol de parseo que genera su compilador.
- ANTLR:
No van a tener que escribir el AST desde cero. ANTLR promueve la separación de la lógica de aplicación separada de definición de la gramática.
Para esto, provee dos mecanismos,Tree Visitors, oTree Listeneres. ANTLR genera una implementación básica de estos mecanismos para recorrer su arbol de parseo.
Pueden encontrar más información acerca de ANTLR (incluyendo el manual y algunos ejemplos) en antlr.org.
ANTLR no genera elTree Visitorpor defecto, pero esto se le puede indicar durante el proceso de generación del parser.
java org.antlr.Tool -visitor -lib scanner/ parser/Decaf.gGIT
Todo el código debe estar actualizado en su repositorio de github, los issues identificados y la documentación también debe ser publicada en github a través del gestor de issues y del wiki.
¿Qué debe entregar?
Debe enviar los fuentes de su proyecto y la documentación del mismo. Su documentación debe incluir las siguientes partes:
-
Una lista de clarificaciones, suposiciones, o adiciones al problema asignado. Las especificaciones del proyecto son bastante amplias: dejan muchas decisiones al implementador (ustedes), lo cual es un aspecto real de ingeniería de software y es mejor que empiecen a acostumbrarse. Si necesitan alguna clarificación, consulten a un auxiliar.
-
Un resumen de su diseño.
-
Una desecripción de su diseño top-level, análisis de alternativas de diseño que consideraron, y decisciones claves de diseño. Asegurense de documentar y justificar cualquier decisión de diseño que tomen. Cualquier decisión acompañada de un argumento convincente va a ser aceptada. Si se dan cuenta que hay errores o deficiencias en su diseño muy tarde en el proceso de implementación discutan estos errores y expliquen qué habrían hecho de manera diferente para evitar el problema.
-
Una descripción de su diseño para módulos no triviales.
-
Cualquier cambio que hayan tenido que realizar en etapas anteriores y por qué fueron necesarios estos cambios.
-
Una breve descripción de temas de implementación interesantes. Esto debe incluir cualquier algoritmo, técnica, y estructura de datos no trivial.
-
Una lista de problemas conocidos de su compilador, y tanta información como le sea posible acerca de la causa de estos problemas. Si su proyecto falla alguno de los casos de prueba, y no pueden arreglar el problema, describan lo que entienden acerca del problema. Si descubren problemas que no pueden arreglar en su proyecto usando sus propias pruebas y estos problemas no son atrapados por los casos de prueba provistos, describan el problema tan específicamente como les sea posible. Si esto causa que su proyecto falle los casos de prueba escondidos, puede que todavía reciban puntos por considerar el problema. Si el problema no es revelado por los casos de prueba escondidos, no se les penalizará.
Asegurense de incluir una descripción completa de cómo su AST está organizado.
Su compilador debe debe asumir que el target default es AST.
Su compilador (cuándo se usa ast como target) debe tener como salida una representación en texto del AST construído.
Además recuerde que su compilador debe soportar un modo de debug en el que todos los nodos del AST sean impresos de alguna forma. Esto puede ser activado desde la línea de comandos, mediante:
java Compiler -debug ast <filename>Entrega
La entrega se realizará a través del GES antes de las 23:55:00 del día Lunes 15 de Septiembre de 2014, debe enviar un archivo llamado grupo.zip conteniendo todas sus clases y demás archivos indicados previamente.
Al desempaquetar su entrega, debemos poder ejecutar su proyecto de la siguiente forma:
java Compiler [option] <filename>Si no se cumple lo anterior, se verán en riesgo de recibir una penalización del 50%, por lo que tenga mucho cuidado con esto.