Tras una pequeña pausa (entre otras cosas por un problema con Eclipse) retomo la resolucion de la practica. Ahora tocan las definiciones de procedimientos.
Aqui tenemos una de las partes que se diferencia entre ambos grupos de la practica, asi como mi enfoque de hacer TODA la especificacion.
Además, la documentacion está mal diseñada e incompleta, con lo que es necesario recurrir a los casos de prueba para realizar el diseño.
Veamos una serie de ejemplos validos de la primera linea de la declaracion de un procedimiento:
PROCEDURE proc0;
PROCEDURE proc1(var1,var2:INTEGER;var3:BOOLEAN);
PROCEDURE proc2(var1,var2:INTEGER;var3:BOOLEAN): BOOLEAN;
PROCEDURE proc3(VAR var1,var2:INTEGER; VAR var3:BOOLEAN):INTEGER;
PROCEDURE proc4:INTEGER;
PROCEDURE proc5:tipoCompuesto;
PROCEDURE proc6(VAR var1, var2: INTEGER; var3:BOOLEAN): tipoCompuesto;
Todos estos son validos o no, dependiendo del grupo al que se pertenezca, y el ultimo no es valido en ninguno de los grupos, pero si en mi especificacion.
A esta primera linea la voy a denominar "cabecera", y voy a seguir definiendo.
declaracionProcedimientos::=declaracionProcedimiento declaracionProcedimientos|/*epsilon*/;
declaracionProcedimiento::= cabecera declaraciones BEGIN sentencias END IDENTIFICADOR PUNTOYCOMA;
Esto es basicamente una copia de la descripcion del programa que lo contiene, e incluye la posibilidad de anidar procedimientos.
Vamos ahora a la cabecera y a cada uno de sus campos.
declaracionProcedimiento::= PROCEDURE IDENTIFICADOR argumentos tipoSalida PUNTOYCOMA;
argumentos::= /*epsilon*/|ABRIR_PARENTESIS listaArgumentos CERRAR_PARENTESIS;
listaArgumentos::= listaIdentificadores DOSPUNTOS tipoPrimitivo
|listaIdentificadores DOSPUNTOS IDENTIFICADOR
|listaIdentificadores DOSPUNTOS tipoPrimitivo PUNTOYCOMA listaArgumentos
|listaIdentificadores DOSPUNTOS IDENTIFICADOR PUNTOYCOMA listaArgumentos;
listaIdentificadores::=listaIdentificadoresValor|listaIdentificadoresReferencia;
listaIdentificadoresValor::=IDENTIFICADOR listaIdentificadoresValor|IDENTIFICADOR;
listaIdentificadoresReferencia::=VAR listaIdentificadoresValor;
Y en principio esto es todo por hoy. Todavía tengo que probarlo, porque no lo haré hasta el final, pero debería funcionar.
Un saludo.
Buenas! Vuelvo a contactar contigo para consultar una duda respecto al tratamiento de errores sintácticos, ya que no subiste ningún post hablando de esto, creo que sería interesante darle una vuelta. Según he leído en los foros de la asignatura y documentos de la práctica, sería suficiente con añadir una nueva regla 'error' para cada uno de los no terminales que forman la estructura de la gramática, ¿Tú lo hiciste así?
ResponderEliminarComo ya comentaba, el proyecto lo tengo inconcluso, por eso faltan cosas como esta. Aqui tienes dos lineas de como hice para manejar los errores:
Eliminar// Gestion de errores
variable ::= IDENTIFICADOR PUNTO error {: syntaxErrorManager.syntaxError("VARIABLE: Se esperaba el campo del registro"); :};
sentenciaReturn ::= RETURN expresion error {: syntaxErrorManager.syntaxError("RETURN: Se esperaba punto y coma"); :}
| RETURN PUNTOYCOMA {: syntaxErrorManager.syntaxError("RETURN: La especificacion del lenguaje no soporta sentencias RETURN vacias"); :};
Asi es como se tratan los errores en la práctica de longinos, pero en un documento de preguntas frecuentes que hay asociado a la práctica en la página de la asignatura dice que se traten de otra forma, te lo pongo en un ejemplo también:
EliminarsentenciaWhile ::= WHILE expresion DO sentencias PUNTOYCOMA END PUNTOYCOMA | error;
sentenciaReturn ::= RETURN expresion | error;
Y luego en la clase correspondiente se trata el error, al llegarle el token error, que se declara como un no terminal.
Por cierto otro problema que tengo ahora mismo es que no se como obtener la herramienta ant, ni como se utiliza, algún tutorial o sugerencia para hacerlo?
Gracias!
Vale, ya me he dado cuenta que tengo el complemento ant en mi ecplipse, asi que no hace falta descargarlo jajaja ahora voy a investigar a ver si se usarlo.
ResponderEliminar