Un bucle for que solo se ejecuta una vez es un tipo de error particularmente cruel. No falla. No lanza un error. Se ejecuta, produce salida y se detiene -- dándote justo la evidencia suficiente para pensar que funciona mientras oculta el resto. La primera iteración tiene éxito, creando una falsa sensación de corrección. Solo cuando examinas los resultados cuidadosamente notas que un bucle sobre tres elementos produjo solo un resultado.
Este era el estado de los bucles for de FLIN el 6 de enero de 2026. Tomó dos sesiones dedicadas -- Sesión 061 y Sesión 062 -- para desenredar lo que resultaron ser dos errores en capas, cada uno escondiéndose detrás del otro.
Error uno: el desbordamiento de pila
El primer síntoma no fue sutil. Ejecutar cualquier bucle for producía un error de desbordamiento de pila durante la limpieza de ámbito. El problema era que las variables de bucle se almacenaban directamente en locals vía el opcode NextFor, pero end_scope() intentaba hacer pop de ellas de la pila como si fueran variables regulares. La corrección agregó un flag is_loop_var al struct Local.
Error dos: el problema de una sola iteración
Después de corregir el desbordamiento de pila, el bucle ya no fallaba, pero solo se ejecutaba una vez. La investigación reveló que las llamadas a funciones nativas no limpiaban el objeto de función de la pila. Después de la primera iteración, la pila contenía el objeto de función de print donde StartFor esperaba encontrar el iterador.
La corrección de tres líneas: hacer pop del resultado, hacer pop del objeto de función, hacer push del resultado de vuelta.
rustCallInfo::Native { arity: native_arity, index } => {
self.execute_native_call(index)?;
let result = self.pop()?; // Pop result
self.pop()?; // Pop function object
self.push(result)?; // Push result back
}El patrón de errores en capas
La saga del bucle for es un ejemplo de libro de texto de errores en capas -- múltiples problemas independientes que interactúan para producir un único síntoma visible. La Capa 1 enmascaraba la Capa 2. La Capa 2 enmascaraba la Capa 3. Cada corrección pelaba una capa, revelando el siguiente problema.
La corrección de tres líneas que resolvió el error de iteración es quizás la mejor ilustración de una verdad universal en la ingeniería de software: la dificultad de un error no es proporcional al tamaño de su corrección, sino al tamaño del espacio de búsqueda que debes navegar para encontrarlo.
Esta es la Parte 157 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: - [156] El opcode CreateEntity que desapareció - [157] El error de iteración del bucle for (estás aquí) - [158] El error de manejo de None