En la recién pasada semana tuvimos la oportunidad de trabajar en grupo, con lo cual nos compartimos algunas ideas, y, aunque ya se dijo que no hay que perder mucho tiempo con el IDE, sucede ser que tengo esa manía.
Entre otras actividades no muy productivas relacionadas con el compilador, comento que es bastante cómodo tener sintaxis coloreada en los archivos de cup y flex. En jCreator 2.00 es bastante fácil, pues entre las configuraciones del editor, uno puede escoger bajo el nodo Editor/Default, un archivo de sintaxis.
Debo decir que me resulto muy fácil crear un nuevo archivo.syn para la versión 2.00, que usa un simple archivo de texto, no obstante la versión 3.50 de jCreator, usa un archivo en formato xml, el cual no quise indagar.
El siguiente paso sería escoger que colores desea usar.
Por alguna razón insisto bastante con los colores, siempre paso un tiempo considerable con ello, como dije antes, esa es [una de mis tantas] manía[s].

Integración Total

Muchos me han preguntado como generar el Javadoc usando jCreator. Ignoro como se hace en otras versiones, pero la versión 2.00 no tiene el comando a la vista entre los menús.
La idea que me vino a la mente, no es osa del otro mundo: Si configuré dos herramientas para generar código, como fue el caso de los archivos.bat que mencioné en el blog anterior, ¿Cuál es la diferencia con Javadoc? Sólo dos: No se usa un .bat, sino un .exe y no se genera código de java, sino de HTML.
Asi es, los pasos son los mismos, solo hay que fijarse un poco con los comandos:
primero, al elegir el nuevo programa, dirigirse a la carpeta donde estan los programas de la JVM, en mi caso esto era:
C:\j2sdk1.4.2_04\bin
Después al configurar la herramienta, usar los siguientes campos:
Commands = C:\j2sdk1.4.2_04\bin\javadoc.exe -d doc -private
Arguments = $[JavaFiles]
Initial Directory = $[PrjDir]

La opción -d permite especificar un directorio de salida, en mi caso -d doc usará una carpeta llamada doc, la cual creé previamente en la carpeta del proyecto ($[PrjDir]), esto para evitar que los elementos del Javadoc se mezclen y/o confundan con mis archivos de código fuente.
La opción -private hace que se incluyan las clases privadas. Sin esta opción, no me documentaba la clase Yylex. (Agradecemos la colaboración de Osman Santos en la averiguación de este pequeño detalle)

Para el campo Arguments, recomiendo utilizar el boton que despliega el menu, y utilizar la opción Project Java Files, y en Initial Directory, la opción Project Directory.

Los Cuarenta Tokens

Lo admito: ¡me encanta jFlex!
Comparándolo con los recuerdos de mi experiencia con ANTLR, puedo afirmar que me siento mucho más confiado con JFLEX.
Aunque al principio no me gustó la documentación, hay que reconocer, que para todo se requiere paciencia, asi que puse esta trillada frase en práctica y leí una buena porción.
Encontré de gran ayuda el ejemplo en el cual especifican parte de la sintaxis de Java, del cual tomé varias ideas, en especial para reconocer strings y secuencias de escape. En realidad no estoy muy seguro de si aplican las secuencias de escape en Pascal, pero por motivos de práctica, intenté hacer que funcionara como en C.

En general, para el lexer, mi estrategia se basa en dos ideas:

1) Los errores deben estar bajo mi control, no bajo el de Yylex, asi los puedo reportar de manera conveniente. y

2) Hay que hacer reglas para aceptar tokens correctos, y reglas para capturar errores.

Lo segundo se debe a algo muy sencillo: si el token está correcto, no hay problema, Yylex lo reconocerá y lo retornará al parser. Pero si el token está mal escrito, Yylex nos dará un extenso y casi ininteligible mensaje de error, ya que el error ocurirá internamente en Yylex, no el el código fuente que estemos analizando.
Además: en algunos puntos es más fácil (con JFlex) hacer las reglas para capturar errores, que hacer expresiones regulares perfectas.
Por ejemplo para los comentarios: es más facil irse a un estado aparte, y tirar el error de anidamiento si encontramos una apertura de comentario, que hecer la expresión regular que admita comentarios sin anidamiento. Aparte, si la ER no reconoce comentarios con anidamiento, el error "lo reportará Yylex", en lugar de "reportarlo yo"

El huevo y la gallina

Para probar el Lexer usé esto:
-------- empieza código -------------
package Jahaz;

import java_cup.runtime.*;
import java.io.*;

/**
Clas Comodo, calache para probar el Yylex solo.
@autor Gerson Lara

*/

public class Comodo{
public static void main(String args[]) throws Exception {
System.out.println("Bienvenido a Comodo");
//Yylex alex = new Yylex(System.in);
FileReader fis = new FileReader("hola.pas");
Yylex alex = new Yylex(fis);
int a = 0;
while(a < 1000){
alex.next_token();
//System.out.print("");
a++;
}
}
}
---------- fin de código --------------

Con esto puedo especificar un archivo en el cual coloco una serie de Tokens, que no tienen porque estar en orden gramatical, unos de ellos bien escritos, pero la mayoria de ellos con errores, así me cercioro de que mi lexer captura los errores y los reporta adecuadamente.

Si ese era el huevo, ahora la gallina:
para que el lexer pueda retornar todos los tipos de token, hay que declararlos como terminales en el archivo de CUP y generar y compilar ese codigo, para que la clase sym esté disponible.

Notas sobre los nombres

Mi compilador se llama Comodo ( no es Cómodo, no lleva el acento en la primera o) y como se lo han de imaginar, se debe al Dragón de Comodo, por ser un dragón real que existe hoy en dia.

El lexer se llama Alex por que es un Analizador LEXico
Este compilador será algo así como "El Show de Alex, Parseo y Semita"
Parseo suena como a Perseo, algo griego, pero no se qué. Y Semita por SEMántico.

Si no les da risa, lo entiendo, de por sí, es sabido que no soy bueno para los chistes, y peor a la hora de este post.

Hasta la próxima, ¡y no dejen de buscar al IDEal!!!