Serialización: una tabla convertida en Lua

La serialización cierra el nivel porque es el problema donde convergen todas sus piezas. Convertir una tabla en texto es un ejercicio de veinte líneas mientras la tabla sea un árbol de valores simples; deja de serlo en cuanto aparece un ciclo, en cuanto dos ramas apuntan al mismo objeto, en cuanto un campo contiene una función y en cuanto alguien propone mandar el resultado por la red. Cada una de esas complicaciones enseña algo distinto sobre qué es realmente un valor en Lua, y la respuesta —que un valor es su contenido más su identidad más el mundo al que se refiere— explica por qué unas cosas cruzan la frontera intactas y otras no pueden cruzarla en absoluto.

La tabla como código fuente

La versión directa aprovecha que la sintaxis del constructor de tablas ya es un formato de datos y que %q produce constantes exactas. Solo hacen falta dos decisiones: cuándo una clave puede escribirse como nombre y cuándo hay que indexar por corchetes, y cómo separar la parte secuencial del resto.

local reservadas = {
  ["and"] = true, ["break"] = true, ["do"] = true, ["else"] = true,
  ["end"] = true, ["for"] = true, ["function"] = true, ["if"] = true,
  ["local"] = true, ["nil"] = true, ["not"] = true, ["or"] = true,
  ["return"] = true, ["then"] = true, ["while"] = true,
}

local function es_nombre(k)
  return type(k) == "string"
     and string.match(k, "^[%a_][%w_]*$") ~= nil
     and not reservadas[k]
end

local function serializar(v)
  local t = type(v)
  if t ~= "table" then return string.format("%q", v) end

  local piezas, n = { "{" }, #v
  for i = 1, n do
    piezas[#piezas + 1] = serializar(v[i]) .. ","
  end
  for k, x in pairs(v) do
    if not (math.type(k) == "integer" and k >= 1 and k <= n) then
      local clave = es_nombre(k) and (k .. "=") or ("[" .. serializar(k) .. "]=")
      piezas[#piezas + 1] = clave .. serializar(x) .. ","
    end
  end
  piezas[#piezas + 1] = "}"
  return table.concat(piezas)
end

La lectura de vuelta es la lección 20.2 aplicada con la máxima restricción posible:

local datos = load("return " .. texto, "=datos", "t", {})()

Ese entorno vacío no es un adorno. Un texto compuesto exclusivamente de literales no nombra nada, así que no necesita ningún global para evaluarse; si el texto intentara llamar a una función, fallaría con un error de indexación en lugar de ejecutarla. Un serializador cuyo formato de salida es código convierte así la carga de datos ajenos en una operación con una superficie de ataque nula por construcción, siempre que el modo sea "t" y el entorno esté vacío. Es una propiedad notable, y se pierde entera si alguien decide que sería cómodo permitir una función auxiliar dentro del formato.

Ciclos e identidad compartida

El serializador anterior entra en recursión infinita en cuanto una tabla se contiene a sí misma, aunque sea a través de tres saltos. Y tiene un defecto más silencioso y a menudo peor: si dos campos apuntan a la misma tabla, la escribe dos veces, y al releer aparecen dos tablas distintas que ya no son iguales por identidad. Un grafo acíclico con estructura compartida en profundidad crece exponencialmente al aplanarlo en un árbol.

La solución a ambos problemas es la misma y consiste en dejar de emitir una expresión para emitir un programa: primero se declara una variable local por cada tabla del grafo, después se rellenan sus campos, y al final se devuelve la raíz.

local function literal(v, id)
  if type(v) == "table" then return id[v] end
  return string.format("%q", v)
end

local function serializar_grafo(raiz)
  local id, orden, decl, asig = {}, {}, {}, {}

  local function registrar(t)
    if id[t] then return end
    id[t] = "_" .. (#orden + 1)
    orden[#orden + 1] = t
    decl[#decl + 1] = "local " .. id[t] .. " = {}\n"
    for k, v in pairs(t) do
      if type(k) == "table" then registrar(k) end
      if type(v) == "table" then registrar(v) end
    end
  end

  registrar(raiz)
  for _, t in ipairs(orden) do             -- orden estable, no pairs(id)
    for k, v in pairs(t) do
      asig[#asig + 1] = string.format("%s[%s] = %s\n",
        id[t], literal(k, id), literal(v, id))
    end
  end
  return table.concat(decl) .. table.concat(asig) .. "return " .. id[raiz]
end

Tres detalles justifican cada línea. El registro previo de todas las tablas antes de rellenar ninguna es lo que rompe el ciclo: cuando se asigna un campo que apunta a una tabla aún no rellenada, la variable ya existe. La tabla id mapea cada tabla a su nombre y, al consultarse en literal, hace que dos referencias al mismo objeto emitan el mismo identificador, de modo que la identidad se conserva al releer. Y la segunda fase recorre orden y no id, porque iterar una tabla con claves de tipo tabla produce un orden que cambia entre ejecuciones: hacerlo sobre la lista ordenada es lo que convierte la salida en determinista, y sin determinismo no hay diferencias legibles ni sumas de verificación estables.

Lo que este esquema sigue sin salvar hay que decirlo: las metatablas. Una tabla con __index o con __eq se serializa como sus campos crudos y renace sin comportamiento. Salvarla exige nombrarla en un registro que exista en los dos extremos, que es exactamente la solución que veremos para las funciones.

flowchart TD
V[Valor a serializar] --> Q[Numero cadena booleano o nil]
Q --> OK[Sobrevive exacto con la conversion q]
V --> T[Tabla]
T --> D[Se registra y recibe un nombre local]
D --> C[Los ciclos y el reparto se conservan]
T --> M[Su metatabla no viaja]
V --> F[Funcion]
F --> B[string.dump salva el bytecode]
B --> U[Los upvalues no viajan]
V --> X[Userdata hilo o funcion de C]
X --> N[No hay representacion posible]

string.dump y lo que el bytecode no lleva

string.dump(f, strip) devuelve un chunk binario con el prototipo compilado de una función de Lua. Falla con las funciones de C, que no tienen bytecode que volcar. El resultado se recarga con load en modo "b", y ahí empieza lo interesante.

local function contador()
  local n = 0
  return function() n = n + 1; return n end
end

local c = contador()
c(); c()                                 -- n vale 2
local copia = load(string.dump(c), "=copia", "b")
print(copia())                           -- error, no devuelve 3

El manual lo dice con una frase que conviene leer dos veces: de las funciones con upvalues solo se guarda el número de upvalues, y al recargarlas reciben valores nuevos. La razón es estructural y ya la conoces del nivel 8: un upvalue no es parte del prototipo sino de la closure, y su valor puede ser cualquier cosa del grafo vivo del programa, incluida otra closure o un userdata. Volcar una closure completa exigiría volcar el mundo entero al que alcanza.

El fallo concreto del ejemplo es más instructivo todavía. Cuando load termina, si la función resultante tiene al menos un upvalue, instala el entorno en el primero, sea cual sea su nombre. Lua no comprueba que se llame _ENV: en un chunk principal ese primer upvalue siempre es el entorno, pero en una closure cualquiera el primero es el que el compilador colocó ahí, que aquí es n. La copia arranca, por tanto, con n valiendo la tabla global, y la suma falla con un error de aritmética sobre un valor de tipo tabla. Es un caso perfecto de una regla razonable aplicada fuera del contexto para el que se escribió.

Reconstruir el estado a mano es posible con debug.setupvalue para cada upvalue, y con debug.upvaluejoin cuando dos closures compartían el mismo, porque asignar el mismo valor a las dos por separado produce dos celdas independientes y el reparto se pierde. En la práctica esto significa que las funciones no se serializan: se serializa su identidad. El patrón que funciona es un registro de funciones con nombre presente en los dos extremos; se emite el nombre como cadena y se resuelve al cargar. Los datos viajan, el comportamiento se acuerda.

El segundo argumento, strip, elimina la información de depuración: números de línea, nombres de locales y de upvalues, nombre del chunk. Reduce el tamaño de forma apreciable y a cambio convierte cualquier error futuro en un mensaje sin archivo ni línea. Es una opción para distribuir, nunca para diagnosticar.

Qué garantiza la cabecera

Un chunk binario empieza con una cabecera cuyo contenido es una lista de comprobaciones, y entenderla evita tanto el optimismo como el miedo. Lleva la firma del formato, el byte de versión del lenguaje, un byte de formato, una secuencia de bytes de control elegida para detectar que el transporte ha alterado saltos de línea o ha truncado el octavo bit, los tamaños en bytes de la instrucción, del entero y del flotante, y por último un entero y un flotante de prueba con valores conocidos.

Ese último par es el más elegante: si el número recuperado no coincide, la máquina que graba y la que lee difieren en el orden de los bytes o en la representación de los flotantes, y la carga se rechaza. La cabecera cubre, por tanto, versión del lenguaje, integridad del transporte, anchura de los tipos numéricos, orden de bytes y formato de coma flotante.

Y no cubre nada más. No hay verificación del cuerpo: un binario cuyo cuerpo haya sido manipulado pasa la cabecera y entra en la máquina virtual con índices de registro, saltos y constantes que el compilador nunca habría generado. Eso no produce un error de Lua, produce accesos fuera de límites en el proceso anfitrión. De ahí la regla que ya enunciamos en 20.1 y que ahora se entiende del todo: el bytecode es una caché local, útil para acelerar el arranque en la misma máquina y con el mismo binario del intérprete, y jamás un formato de intercambio. Entre versiones de Lua el formato cambia sin compromiso de compatibilidad, y el de LuaJIT es otro distinto por completo.