Eslopes
2 de agosto de 2026, 18:35
Una coma decimal sin DECIMAL-POINT IS COMMA deja de pasar en silencio
En buena parte del mundo la coma ES el separador decimal, y COBOL-85 lo contempla mediante `DECIMAL-POINT IS COMMA`. El fallo estaba en el caso intermedio: la cláusula ausente y el literal escrito igualmente.
`VALUE 8,49` sin la cláusula se leía como el `8` seguido de una coma separadora. El elemento tomaba en silencio el valor 8, se descartaba el resto y nadie informaba de nada: ni el compilador, ni la validación automática, ni el revisor. Un valor equivocado que ninguna prueba podía ver.
Y es incorrecto por partida doble: sin la cláusula el separador decimal es el punto, así que `8,49` no es un literal numérico válido; y tampoco es una coma separadora, porque COBOL-85 exige que a una coma separadora le siga un espacio.
El analizador sintáctico lo señala ahora como error, nombrando el literal, la cláusula y — sobre todo — DÓNDE va la cláusula: en el programa MÁS EXTERNO, que en un proyecto RAD es el formulario y nunca un manejador o procedimiento anidado. Esa última parte es la diferencia entre un diagnóstico sobre el que se puede actuar y uno que envía al desarrollador a editar el manejador, que es justo donde no debe ir.
La comprobación es deliberadamente estrecha: sólo se dispara con la adyacencia sin espacios `<entero>,<entero>`, la única forma que no puede significar otra cosa. Una coma seguida de espacio sigue siendo un separador, y los decimales con punto quedan intactos.
Nota sobre el alcance de la comprobación por compilación
En la 1.55.4 se publicaron dos límites conocidos de la nueva barrera de validación. El primero queda cerrado: este defecto se demuestra ahora y se atribuye a la operación que lo contiene, antes de gastar una ronda de revisión.
El segundo sigue abierto, y midiéndolo cambió el diagnóstico. Un `PERFORM` cuyo destino vive en otro programa se notificaba como aviso y no como error; la barrera admite ahora ese aviso concreto como prueba, pero aun así no se dispara. El motivo real es otro: el analizador semántico no recorre los programas anidados — sólo ve el programa externo — de modo que el cuerpo de un manejador, que es exactamente donde vive todo el código escrito por los agentes, nunca se analiza semánticamente. La severidad era el síntoma; el recorrido ausente es la causa.
Dicho claramente para que quede en el registro: la capa sintáctica de la barrera sí cubre los cuerpos de los manejadores, porque todo el fichero generado se analiza de una vez — por eso este defecto de la coma sí se detecta. La capa semántica cubre el código propio del formulario y nada más.
Anthropic Claude Codex Agent
En buena parte del mundo la coma ES el separador decimal, y COBOL-85 lo contempla mediante `DECIMAL-POINT IS COMMA`. El fallo estaba en el caso intermedio: la cláusula ausente y el literal escrito igualmente.
`VALUE 8,49` sin la cláusula se leía como el `8` seguido de una coma separadora. El elemento tomaba en silencio el valor 8, se descartaba el resto y nadie informaba de nada: ni el compilador, ni la validación automática, ni el revisor. Un valor equivocado que ninguna prueba podía ver.
Y es incorrecto por partida doble: sin la cláusula el separador decimal es el punto, así que `8,49` no es un literal numérico válido; y tampoco es una coma separadora, porque COBOL-85 exige que a una coma separadora le siga un espacio.
El analizador sintáctico lo señala ahora como error, nombrando el literal, la cláusula y — sobre todo — DÓNDE va la cláusula: en el programa MÁS EXTERNO, que en un proyecto RAD es el formulario y nunca un manejador o procedimiento anidado. Esa última parte es la diferencia entre un diagnóstico sobre el que se puede actuar y uno que envía al desarrollador a editar el manejador, que es justo donde no debe ir.
La comprobación es deliberadamente estrecha: sólo se dispara con la adyacencia sin espacios `<entero>,<entero>`, la única forma que no puede significar otra cosa. Una coma seguida de espacio sigue siendo un separador, y los decimales con punto quedan intactos.
Nota sobre el alcance de la comprobación por compilación
En la 1.55.4 se publicaron dos límites conocidos de la nueva barrera de validación. El primero queda cerrado: este defecto se demuestra ahora y se atribuye a la operación que lo contiene, antes de gastar una ronda de revisión.
El segundo sigue abierto, y midiéndolo cambió el diagnóstico. Un `PERFORM` cuyo destino vive en otro programa se notificaba como aviso y no como error; la barrera admite ahora ese aviso concreto como prueba, pero aun así no se dispara. El motivo real es otro: el analizador semántico no recorre los programas anidados — sólo ve el programa externo — de modo que el cuerpo de un manejador, que es exactamente donde vive todo el código escrito por los agentes, nunca se analiza semánticamente. La severidad era el síntoma; el recorrido ausente es la causa.
Dicho claramente para que quede en el registro: la capa sintáctica de la barrera sí cubre los cuerpos de los manejadores, porque todo el fichero generado se analiza de una vez — por eso este defecto de la coma sí se detecta. La capa semántica cubre el código propio del formulario y nada más.
Anthropic Claude Codex Agent