_ENV: la revelación de 5.2

En 2011, Lua 5.2 eliminó las variables globales del lenguaje. No las prohibió: las explicó. Descubrió que nunca habían sido una categoría aparte, sino azúcar sintáctica para un acceso a tabla, y lo hizo explícito con una sola regla de una línea que sustituyó a dos funciones de la biblioteca, a un campo del objeto función y a un concepto entero del manual. Esa regla es la clave que abre todo lo que queda de este nivel, todo el sandboxing de la lección siguiente y buena parte de los idiomas avanzados de Lua. Se enuncia así: el nombre libre x significa _ENV.x. Nada más. Y nada menos.

No existen las variables globales

La regla del manual es literal: toda referencia a una variable global var se traduce sintácticamente a _ENV.var, y todo chunk se compila en el ámbito de una variable local externa llamada _ENV. Las dos frases juntas eliminan el concepto. Este programa:

print("hola", x)
x = 42

es exactamente, para el compilador, este otro:

_ENV.print("hola", _ENV.x)
_ENV.x = 42

De aquí se deduce, sin necesidad de memorizar nada más, todo el comportamiento clásico de los globales. ¿Por qué leer una global no declarada devuelve nil en lugar de dar error? Porque leer una clave ausente de una tabla devuelve nil. ¿Por qué una global escrita mal se crea en silencio? Porque asignar a una clave nueva de una tabla la crea. ¿Por qué se pueden interceptar con una metatabla? Porque el entorno es una tabla y las tablas tienen metatablas. ¿Por qué son lentas comparadas con las locales? Por lo que vimos en 9.2: son un acceso a tabla, y las locales no.

_ENV es un upvalue como cualquier otro

Lo verdaderamente elegante es que _ENV no es una palabra clave ni recibe trato especial en la máquina virtual. Es un nombre corriente, sujeto a las reglas de ámbito corrientes, que resulta estar declarado como upvalue del chunk principal. Se comprueba desde el propio programa:

local function f () return x end       -- 'x' es libre

print(debug.getupvalue(f, 1))          --> _ENV    table: 0x...
print(_ENV == _G)                      --> true en el interprete estandar
print(rawequal(_ENV, debug.getupvalue(f, 1)))  -- comparalo tu mismo

Que sea un nombre corriente implica que puedes declararlo como local, recibirlo como parámetro y sombrearlo igual que cualquier otro:

local function aislada (_ENV)          -- parametro llamado _ENV
  return saludo .. " " .. nombre       -- se leen del parametro, no del global
end

print(aislada({ saludo = "hola", nombre = "mundo" }))  --> hola mundo

En esa función no hay ninguna magia: saludo es libre, luego significa _ENV.saludo, y el _ENV visible ahí es el parámetro. Toda la lección 9.4 es la explotación sistemática de este hecho.

Hay una única precaución, y es lógica: _ENV no debe ser a su vez una variable global. Si lo fuera, _ENV.var se traduciría a _ENV._ENV.var, y ese _ENV a _ENV._ENV._ENV.var, en una regresión infinita. Lua 5.5 ya no confía en tu disciplina y lo convierte en un error de compilación explícito: _ENV is global when accessing variable 'x'. Es una de esas comprobaciones que solo tienen sentido cuando entiendes que la traducción es realmente sintáctica.

_G es solo un nombre más

Aquí se derrumba el malentendido más extendido del lenguaje. _G no es el mecanismo de los globales: es una variable global corriente que el intérprete inicializa apuntando al entorno global, para que puedas manipular esa tabla por su nombre. El manual es tajante: _G nunca se usa internamente, así que cambiar su valor solo afecta a tu propio código.

_G = "ya no es una tabla"     -- perfectamente legal
print("sigo funcionando")     --> sigo funcionando

El programa sigue vivo porque print se resolvió vía _ENV, no vía _G. El verdadero entorno global es un valor guardado en el registro de C, en el índice LUA_RIDX_GLOBALS; _G y el _ENV inicial de cada chunk son dos nombres que empiezan apuntando a él. Manipular _G.foo funciona sencillamente porque, mientras nadie los separe, son la misma tabla.

Que sean la misma tabla por defecto no significa que tengan que serlo. En cuanto separas los dos nombres, la diferencia salta a la vista:

local viejo_G = _G
local _ENV = { print = viejo_G.print, _G = viejo_G }   -- entorno propio

x = 1                        -- va a la tabla nueva
print(x)                     --> 1
print(_G.x)                  --> nil   el entorno global no se ha tocado
_G.y = 2                     -- escribe en el global de verdad
print(y)                     --> nil   'y' se busca en la tabla nueva

Esta distinción es la que hace posible el sandboxing. Si _G fuera el mecanismo, no habría forma de darle a un chunk un conjunto distinto de globales. Como el mecanismo es _ENV y _ENV es una variable léxica, basta con darle otro valor.

flowchart TD
A[El compilador encuentra el nombre saludo] --> B[Hay local o upvalue con ese nombre]
B -- si --> C[Acceso lexico directo]
B -- no --> D[Se reescribe como _ENV.saludo]
D --> E[Que _ENV es visible aqui]
E --> F[El upvalue implicito del chunk]
E --> G[Un parametro o una local llamada _ENV]
F --> H[Entorno global del registro de C]
G --> I[Entorno propio de esa funcion o bloque]

De setfenv a _ENV: por qué el cambio

Lua 5.1 resolvía lo mismo con setfenv(f, tabla) y getfenv(f): cada función llevaba un campo con su entorno, y podías cambiarlo en tiempo de ejecución, incluso indicando un nivel de la pila de llamadas. Funcionaba, y aun así se eliminó por completo en 5.2. Las razones son un caso de estudio de diseño de lenguajes.

• Era dinámico, no léxico. Leyendo una función no podías saber a qué entorno accedían sus nombres libres: dependía de quién hubiera llamado a setfenv antes, quizá desde otro módulo. Ningún análisis estático era posible.
• Manipulaba la pila de llamadas. setfenv(1, t) afectaba a la función actual según el nivel; con corrutinas y llamadas de cola la semántica se volvía sutil hasta la fragilidad.
• Exigía un campo por función. Cada objeto función cargaba con un puntero de entorno, y el intérprete con un caso especial en cada acceso a global.
• No componía. Anidar entornos, heredar de uno externo o dárselo a un bloque en lugar de a una función eran problemas sin solución limpia.

Lo que se ganó a cambio se resume en cuatro capacidades que en 5.1 no existían o eran acrobacias:

La sustitución es una lección de economía: _ENV no añadió nada al lenguaje. Reutiliza el mecanismo de upvalues que ya existía, reutiliza las reglas de ámbito que ya existían y reutiliza el acceso a tabla que ya existía. La máquina virtual solo necesita una instrucción, GETTABUP, que ni siquiera es específica de los globales: significa “indexa un upvalue”. Se borraron dos funciones de la biblioteca, un campo de la estructura de función y un concepto del manual, y a cambio el lenguaje ganó expresividad.