Globales declarados: la gran novedad de Lua 5.5

Durante más de treinta años, Lua tuvo un agujero que todo el mundo conocía y nadie podía cerrar sin romper el lenguaje: escribir mal el nombre de una variable no era un error, era una creación. Un contdaor en lugar de contador compilaba, se ejecutaba y devolvía nil en silencio, quizá dentro de una rama que solo se toma un martes al mes. En diciembre de 2025, Lua 5.5 cerró el agujero con la novedad más comentada de la versión: la palabra clave global, que permite declarar variables globales igual que se declaran las locales, y hacer que usar una no declarada sea un error de compilación. Esta lección la desmonta entera, porque es el cierre natural de todo el nivel.

El bug de treinta años

El problema no era que Lua tuviera globales, sino que no tenía forma de distinguir una global intencionada de un error tipográfico. Las dos se escriben igual:

local function acumular (t)
  local total = 0
  for _, v in ipairs(t) do
    totla = totla + v          -- error: lee nil, suma, revienta o no
  end
  return total
end

Ese código compilaba sin una queja en toda la historia anterior del lenguaje. Y la razón es exactamente lo que aprendimos en 9.3: totla no es una variable no declarada, es _ENV.totla, y leer una clave ausente de una tabla es una operación perfectamente legal que devuelve nil. El compilador no podía protestar sin dejar de ser correcto, porque el programa es correcto según la semántica del lenguaje.

La comunidad convivió con paliativos. El strict.lua de la lección 9.4 pone una metatabla sobre _G y falla en ejecución, solo si esa línea se ejecuta, y a costa de una llamada Lua por acceso. Los analizadores externos como luacheck avisan bien, pero son una herramienta aparte que hay que instalar, configurar y que no todo el mundo ejecuta. Cachear la biblioteca en locales, como en 9.2, reduce la superficie pero no la elimina. Ninguno era el lenguaje diciendo la verdad sobre tu programa.

La sintaxis exacta

Lua 5.5 añade una declaración simétrica a la de locales. La gramática es prácticamente la misma:

stat ::= local  attnamelist [ = explist ]
stat ::= global attnamelist [ = explist ]
stat ::= global [attrib] *
stat ::= global function Name funcbody

En la práctica:

global contador                 -- declara; no toca su valor actual
global maximo = 100             -- declara e INICIALIZA
global <const> VERSION = "1.0"  -- global de solo lectura
global function iniciar () end  -- azucar de: global iniciar; global iniciar = function () end

Cuatro precisiones importan de verdad. Primera: sin inicialización, el valor de la global se deja intacto, a diferencia de una local sin inicializar, que vale nil. Segunda: la inicialización lanza un error de ejecución si la variable ya estaba definida con un valor no nulo; es una protección deliberada contra redefinir por accidente algo que ya existe, y es lo que hace valiosa la forma global function. Tercera: el atributo const está disponible para globales, mientras que close sigue siendo exclusivo de las locales. Cuarta: el ámbito de una declaración global sigue las mismas reglas léxicas de 9.1 —empieza en la sentencia siguiente y termina con el bloque—, de modo que puede declararse dentro de un do ... end y valer solo ahí.

El preámbulo implícito y el modo estricto

Aquí está el diseño fino, y es lo que permite que Lua 5.5 no rompa el mundo. Todo chunk arranca con una declaración implícita global *, que declara como globales todos los nombres libres. Esa declaración preambular queda anulada dentro del ámbito de cualquier otra declaración global. El ejemplo del manual lo dice todo:

X = 1       -- Ok, global por defecto
do
  global Y  -- anula la declaracion implicita inicial
  Y = 1     -- Ok, Y esta declarada
  X = 1     -- ERROR, X no esta declarada
end
X = 2       -- Ok, global por defecto otra vez

La regla resultante es de una economía notable: fuera de toda declaración global, Lua funciona como siempre; dentro de una, no hay valor por defecto y todo debe declararse. El modo estricto no es una bandera del intérprete ni una opción de compilación: se activa escribiendo una sola declaración.

La forma colectiva con asterisco da el control fino. global * restaura el comportamiento clásico de lectura y escritura libres; global <const> * declara como globales de solo lectura todos los nombres no declarados antes. Esa segunda forma es la cabecera práctica que conviene adoptar:

-- Cabecera recomendada de un fichero en Lua 5.5
global estado, contador          -- las globales que este fichero ESCRIBE
global <const> *                 -- todo lo demas: lectura libre, escritura prohibida

contador = 0                     -- Ok, declarada como escribible
print(math.pi)                   -- Ok, 'print' y 'math' son de solo lectura
contdaor = 1                     -- ERROR de compilacion: es de solo lectura

Consigues lo mejor de los dos mundos: no tienes que enumerar las cuarenta funciones de la biblioteca estándar que usas, y cualquier escritura accidental a una global —que es la vía por la que entran casi todos los bugs de este tipo— muere al compilar. Si quieres la máxima severidad, declara solo lo que uses y omite el asterisco: entonces también las lecturas de nombres no declarados son un error.

Los mensajes son claros y llegan del compilador, no del programa en marcha. Un nombre no declarado dentro del ámbito estricto da variable 'contdaor' not declared; asignar a una global de solo lectura da attempt to assign to const variable 'contdaor'.

Conviene ver los tres regímenes uno al lado del otro, porque la elección es tuya y se hace fichero a fichero:

Qué cambia y qué no cambia

Conviene ser muy preciso, porque es fácil sobreinterpretar la novedad. El efecto de una declaración global es puramente sintáctico, salvo por la asignación opcional. No crea una tabla nueva, no cambia dónde vive el valor, no altera la traducción de 9.3 y no cuesta nada en ejecución: contador sigue siendo _ENV.contador y sigue compilando a un GETTABUP. Lo que ha cambiado es que ahora el compilador sabe qué nombres tenías intención de usar así, y puede rechazar los demás.

De ello se deducen las limitaciones, todas ellas visibles en el ejemplo del propio manual:

global X <const>, _G
X = 1           -- ERROR, es de solo lectura
_ENV.X = 1      -- Ok: la ruta explicita no pasa por la declaracion
_G.print(X)     -- Ok
foo()           -- 'foo' puede cambiar cualquier global libremente

<const> protege el nombre, no el valor: la ruta explícita por _ENV o por _G sigue abierta, y cualquier función a la que llames puede modificar cualquier entrada del entorno. No es un sistema de tipos, no es inmutabilidad y no es aislamiento —para eso está _ENV, la lección 9.4—. Es exactamente lo que promete: la declaración de intención que faltaba, verificada al compilar y sin coste alguno en ejecución.

flowchart TD
A[El compilador ve un nombre libre] --> B[Estoy dentro del ambito de alguna declaracion global]
B -- no --> C[Preambulo implicito global asterisco]
C --> D[Se acepta como global de lectura y escritura]
B -- si --> E[Ese nombre fue declarado]
E -- si --> F[Acceso normal via _ENV]
E -- no --> G[Hay una forma colectiva previa]
G -- global const asterisco --> H[Lectura permitida y escritura rechazada al compilar]
G -- no la hay --> I[Error: variable no declarada]