Las palabras clave en los fuentes de PSeInt

Siguiendo con los cambios internos en PSeInt, me embarqué en uno de los más trabajosos, que tiene que ver con la posibilidad de variar las palabras claves del pseudocódigo. Veamos el problema, la parte resuelta, la parte que falta, y las ventajas que traerá cuando se complete.

 1. El Problema

El código original de PSeInt estaba pensado para interpretar una única e indiscutible versión del pseudocódigo (reglas y palabras clave), que era la que me enseñaban en la cátedra donde empecé este proyecto. Entonces, por ej, "ESCRIBIR" como constante aparece muchas veces en los fuentes (en varios módulos, y en algunos casos muchas veces en cada uno). Y también con pequeñas variaciones (ej "ESCRIBIR ", con un espacio al final). Si quiero cambiar esa palabra clave, es un problema.

Pero hay más. No alcanza con buscar todos los lugares con dice ESCRIBIR y analizar si es la constante, si agrega espacio o algo, etc. También aparecen en el código otras constantes como 8 representando la "longitud de Escribir", o 9 representado lo mismo más un carácter adicional (como un espacio o un punto y coma). Imaginar y buscar las constantes numéricas es demasiado trabajo.

Hay tanto de esto en el código original de PSeInt.

Cuando empecé a permitir algunas variaciones (como Mostrar en lugar de Escribir, o Algoritmo en lugar de Proceso), fueron todos casos excepcionales, agregados con ifs ad-hoc, normalmente en la etapa de normalización, donde se detecta la palabra alternativa y se reemplaza por la original. Esto complica un poco más el código porque agrega las alternativas como casos particulares. Y no siempre son tan simples como agregar un or a la condición de un if (palabra=="ESCRIBIR" or palabra=="MOSTRAR"), porque hay veces en que una palabra clave se forma en realidad con más de una palabra (Hasta Que, Fin Algoritmo, Para Cada, etc). Estos casos suelen tener más código raro, y no siempre se resuelven de la misma forma.

Con todo esto, permitir modificar un poco más las palabras clave, o incluso agregar alguna nueva, es un dolor de cabeza.

2. La primera mejora

Lo que comenté que había hecho para que todos los módulos puedan reaprovechar el primer parseo que hace el módulo principal (pseint), que consistía entre otras cosas en reemplazar el formato de salida intermedio (el pseudocódigo normalizado) por una estructura de datos mucho más específica, sirvió para que las palabras clave ya no se repitan tanto en todos los módulos. En la nueva estructura de datos, cada instrucción ya viene con su tipo identificado, y sus partes cortadas, por lo que los módulos que consumen esta estructura ya no necesitan de las palabras claves.

Este cambio, que ya está listo hace unas semanas, eliminó la repetición y los números mágicos de módulos como psexport, o psdraw, que eran los más complicados en este sentido. Resta trabajar también sobre wxPSeInt, que como esos cambios no rompían su compilación, no me vi obligado a actualizar todavía. Sacando esto, el problema queda bastante acotado al módulo principal, pseint.

 

3. El trabajo actual

Actualmente estoy en el módulo principal. Los cambios del punto 2 ya lo mejoraron un poco, pero falta bastante. En estos días armé una estructura de datos para representar una palabra clave, para luego hacer que todo análisis de código que busque esa palabra dependa solo de esa estructura. Y ahí se gestiona de forma bastante transparente para el código cliente la posibilidad de palabras alternativas: el cliente compara un string contra el objeto que representa la palabra clave, y la función de comparación se encarga de ver todas las alternativas que guarde el objeto. Y esta función considera también los casos especiales como palabras compuestas por más de una palabra, o cuando una palabra clave es igual al comienzo de otra (ej: Para y Para Cada), y esconde esa complejidad también.

Con todo esto, el código cliente se simplifica mucho en varios casos. Ya lo implementé en la parte de detectar una instrucción (la primer palabra clave), pero por lo mal que está hecho el resto del análisis, no es tan simple hacerlo para las demás (las que van en medio o al final, como Hacer, Hasta, Con Paso, Sin Saltar, etc). Y en eso estoy ahora.

4. Las ventajas a futuro

Cuando esto termine, ya no me costará casi nada personalizar las palabras claves o agregar alternativas. Con tanta libertad que se va sumando, voy a tener que reformatear el cuadro de personalización del lenguaje, y el formato del archivo de perfil, pero finalmente cada docente podrá elegir sus palabras, u ordenar las que ya tenemos de forma que el intérprete priorice la de su preferencia (por ej, al generar código en la GUI o desde el editor de diagramas; o hasta en los mensajes de error y en las ayudas).

Y finalmente esto da pie para empezar a pensar en traducciones a otros lenguajes (pseudocódigo en portugués, francés, o klingon). Este no es un objetivo mio, pero sí me lo han consultado algunos usuarios alguna vez. Si se logra de rebote, bienvenido sea. Faltaría, eso sí, la posibilidad de traducir la GUI además del pseudocódigo, y eso no está implementado ni planeado de momento. Pero si hay suficientes interesados, supongo que en algún punto podría tomar el mecanismo que uso en ZinjaI y adaptarlo.