El opcode duplicado que casi rompió todo

Los peores errores no son los que hacen que su programa se caiga. Los peores errores son los que silenciosamente producen resultados incorrectos. FLIN tenía tal error. Dos implementaciones separadas del mismo opcode, viviendo en el mismo archivo, separadas por 3,418 líneas, produciendo resultados sutilmente diferentes dependiendo de qué ruta de ejecución tomara la VM.

El opcode CreateMap -- responsable de construir cada hash map en cada programa FLIN -- existía en dos formas. Una manejaba claves Value::Text. La otra no. Y durante semanas, los mapas de traducción estaban silenciosamente descartando entradas.

La corrección

La corrección fue quirúrgica -- una rama else if agregada a la versión run() de CreateMap:

rust} else if let Value::Text(s) = key {
    map.insert(s, value);  // <-- LA CORRECCIÓN: manejar Value::Text
}

Una línea de Rust. Tres tokens: else if let. Esa fue la diferencia entre mapas de traducción que funcionaban y mapas de traducción que silenciosamente descartaban entradas.

Lecciones para implementadores de lenguajes

1. Nunca duplicar tablas de despacho. Si dos funciones necesitan manejar el mismo conjunto de opcodes, deben compartir un único mecanismo de despacho.
2. El fallthrough silencioso siempre está mal para despacho de opcodes. Un _ => continue silencioso era la causa raíz de docenas de fallos silenciosos.
3. La elección de representación de valores del compilador nunca debe afectar la semántica.

Esta es la Parte 147 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.

Navegación de la serie: - [146] Auditando 186,000 líneas de código - [147] El opcode duplicado que casi rompió todo (estás aquí) - [148] 30 TODOs, 5 panics en producción, 0 problemas de seguridad