Índice de entradas del conversor
Índice
¿De transpilador a compilador?
Evolución del proyecto y cambio de enfoque
Cuando empecé el proyecto de transpilación de ZX BASIC a SuperBASIC (QL), el objetivo parecía claro y razonable: traducir programas clásicos del Spectrum a un SuperBASIC moderno, legible y ampliable, respetando en lo posible el espíritu original pero sin arrastrar las limitaciones del intérprete de los años 80.
Al principio pensaba que sería relativamente sencillo: tokenizar el programa y traducirlo a un lenguaje muy similar. Sin embargo, paso a paso el proyecto fue complicándose. Empezaron a aparecer casos especiales, decisiones incómodas y pequeñas incoherencias que, aunque no impedían avanzar, sí dificultaban hacerlo bien.
Sin embargo, como suele ocurrir en los proyectos que merecen la pena, el camino no fue lineal. Lo que empezó como un “simple transpilador” acabó convirtiéndose en algo conceptualmente más ambicioso: una cadena de compilación modular, con fases bien definidas, contratos explícitos y decisiones arquitectónicas conscientes.
El punto de partida: traducir, no reinterpretar
Desde el principio hubo varias decisiones claras:
- El código generado debía ser SuperBASIC editable, no un artefacto opaco.
- No se intentaría emular el ZX Spectrum al 100 %:
- nada de
PEEK/POKE - nada de trucos de automodificación
- nada de
- Las funciones ZX no soportadas se resolverían mediante llamadas a rutinas auxiliares escritas en SuperBASIC.
- El resultado debía ser extensible, pensando en mejoras futuras.
El transpilador original funcionaba como un bloque monolítico: leer una línea, analizarla, transformarla y generar código QL.
Funcionaba, pero conforme el proyecto crecía, también crecían las dudas.
El generador fue el primer aviso
El proyecto avanzaba, con cambios en el lexer y el parser por el camino, pero fue el generador el que puso el primer escalón incómodo delante del diseño.
Para generar buen SuperBASIC había que responder a preguntas que un “transpilador rápido” no suele plantearse:
- ¿Cómo se numeran las líneas para facilitar la edición manual?
- ¿Dónde debe ir la inicialización del entorno gráfico?
- ¿Cómo se insertan subrutinas (
PROC) sin romper el flujo? - ¿Qué partes del código son infraestructura y cuáles lógica del programa?
Si el generador necesita un AST claro, el resto del sistema también debería pensarse como un compilador.
Reescribir y replantear no es perder tiempo: es ganar claridad, mantenibilidad y, muchas veces, velocidad.
La ruptura conceptual: dividir en módulos
El diseño monolítico, pensado para optimizar el QL, terminó siendo un error. La decisión clave fue:
Dividir el sistema en módulos independientes, comunicados solo por ficheros.
- Director: orquesta el proceso, sin conocer el lenguaje.
- Lexer: reconoce ZX BASIC y genera tokens.
- Parser: construye el AST.
- Semántico: valida y ajusta el AST.
- Generador: produce SuperBASIC editable.
Primer paso: el fichero .TOK
El fichero .tok es la frontera definitiva entre fases:
- texto plano
- una línea por token
LINE,EOL,EOF- sin posiciones ni contexto oculto
- la única fuente de verdad para el parser
LINE 50
Keyword IF
Identifier C
OpMayorIgual >=
Number 20
Keyword THEN
Keyword GOTO
Number 100
EOL
Si algo no está en el .tok, el parser no lo sabe.
El papel del Director: menos es más
El Director no debe saber si el lenguaje es ZX BASIC, C o Pascal.
El lexer reconoce y valida el número de línea. El Director solo coordina.
El resultado: un lexer cerrado
- Reconoce ZX BASIC correctamente
- Detecta errores léxicos reales
- No adelanta semántica
- Genera un
.tokdefinitivo
Esta fase está cerrada.
Conclusión
El proyecto ya no es solo un transpilador: es una base sólida para un posible compilador real.
El lexer está cerrado, el contrato existe, y el camino es ahora mucho más claro.
Postdata
Este proyecto es complejo y formativo. Revisar, dudar, reescribir y aprender forma parte esencial del proceso.
La ayuda de herramientas como Copilot ha sido clave, siempre revisando, cuestionando y aprendiendo.
No hay comentarios:
Publicar un comentario