Memoria Practica Procesadores Lenguaje UNED

PRÁCTICA DE PROCESADORES DE LENGUAJES
Curso 2012 – 2013
Entrega de Septiembre

APELLIDOS Y NOMBRE:
IDENTIFICADOR:
DNI:
CENTRO ASOCIADO MATRICULADO:
CENTRO ASOCIADO DE LA SESIÓN DE CONTROL:
MAIL DE CONTACTO:
TELÉFONO DE CONTACTO:
GRUPO (A ó B): A

1. Cambios realizados en los analizadores léxico y sintáctico

1.1. Cambios en el analizador léxico
No se han realizadomodificaciones respecto a la entrega de febrero, que a su vez coincidía con la de junio.
1.2. Cambios en el analizador sintáctico
No se han realizado cambios en la gramática presentada en junio. A continuación reproduzco las principales modificaciones respecto a la de febrero, incluidas en la memoria de junio, y que están plenamente vigentes.
Obviando las adiciones consecuencia de las fases posteriores a laprimera entrega, los cambios fundamentales que ha sufrido el parser respecto a aquella han sido los siguientes:
Distinción entre cuerpo del programa principal, cuerpoPpal, y cuerpo de subprogramas, cuerpoPrograma, nombre quizá poco afortunado
Eliminación del no terminal valorConstante ::= LITERAL_ENTERO | literalBoolean, respecto a febrero
Se crea el no terminal referencia, de granimportancia, y se añade a la parte derecha de las reglas de asignaciones y expresiones. Se usa para “recoger” identificadores ya incluidos en la tabla de símbolos, el elemento de un vector y la llamada a un función.
Eliminación del no terminal elseOpcional ::= ELSE listaDeSentencias | ; . Se añade esta posibilidad directamente a sentenciaCondicional.
Eliminación de llamadaFn, como se ha indicado antes almencionar la inclusión como nuevo no terminal de referencia. Este punto resultó especialmente conflictivo y me tuvo sin avanzar bastante tiempo, ya que no lograba por ningún medio que el analizador distinguiera una llamada a una función de un elemento de un vector. Finalmente tras una consulta al equipo docente se me indicó esta solución implementada, eliminándose este no terminal y tratándose,llamada a función y elemento de un vector, como una referencia, realizando previamente las comprobaciones necesarias.

2. El analizador semántico y la comprobación de tipos
Aunque se ha realizado una revisión profunda de las acciones semánticas, modificándose de forma sustancial muchas de ellas, lo esencial que se recogía en junio sigue estando vigente. Reproduzco a continuación lo que entoncesse decía.

Para dar soporte al analizador semántico y dentro del paquete compiler.syntax.
nonTerminal se han creado unas clases de apoyo que hereden de la clase abstracta NonTerminal:
ListaSentencias, para la asignación de atributos gramaticales y agrupar código intermedio para un grupo de sentencias
Exp, para el mismo propósito en expresiones simples
Ref, para las referencias
ListaObjetos,para la relación de argumentos en llamadas de funciones y procedimientos
Parametro, clase de apoyo para los parámetros de funciones y procedimientos. Una vez implementado, descubrí SymbolParameter, pero ya era tanto el trabajo adelantado que opté por seguir usando esta clase
Var, clase de apoyo para la declaración de variables

En cuanto a la comprobación de tipos, se realizan comprobacionespara asegurarse de la compatibilidad de los tipos en expresiones, referencias, asignaciones, en la sentencia condicional y en la sentencia While. Por ejemplo, se ha implementado un método isCompatible para esta clase de comprobaciones en el caso de las expresiones.
2.1. Descripción de la Tabla de Símbolos implementada
Básicamente es la facilitada en el framework de soporte por el equipo docente.Al abrirse un ámbito, scope, se crea una referencia a una tabla de símbolos y a una de tipos inicialmente vacías. Ambas son una estructura de datos de tabla hash donde se registran todas las declaraciones de símbolos y todas las declaraciones de tipos realizadas en ese ámbito.
En la tabla de tipos se insertan los tipos que se van declarando en cada ámbito y que para el grupo A son los tipos...