Personalizar la iteración: `__pairs`, corrutinas y composición

Las cuatro lecciones anteriores han desmontado el protocolo y han mostrado las dos formas de cumplirlo. Queda la parte que convierte todo eso en una herramienta de diseño: intervenir el recorrido ajeno, generar recorridos que serían insoportables de escribir a mano y encadenar iteradores para construir tuberías que no materializan nada. Son tres técnicas de naturaleza muy distinta y con reputaciones opuestas. El metamétodo __pairs es la más tentadora y la más peligrosa, porque hace mentir a una función que todo el mundo cree conocer. Las corrutinas son la más expresiva y la más cara, porque compran una pila entera para poder suspenderse dentro de una recursión. Y la composición es la más humilde y la más rentable, porque no necesita nada que no hayas visto ya y sin embargo reemplaza a bibliotecas enteras de otros lenguajes.

__pairs y el precio de mentir

Cuando pairs recibe un valor cuya metatabla tiene la clave __pairs, no devuelve next y la tabla: llama a ese metamétodo con el valor como único argumento y devuelve los tres primeros resultados de la llamada. El metamétodo se convierte así en la fábrica de la tripleta, y puede devolver la que quiera.

local datos = { alfa = 1, beta = 2, gamma = 3 }

local vista = setmetatable({}, {
  __index = datos,
  __pairs = function()
    local claves = {}
    for k in next, datos do claves[#claves + 1] = k end
    table.sort(claves)
    local i = 0
    return function()
      i = i + 1
      local k = claves[i]
      if k ~= nil then return k, datos[k] end
    end
  end,
})

for k, v in pairs(vista) do print(k, v) end   -- alfa, beta, gamma, siempre

El ejemplo enseña de paso dos detalles del contrato. El primero es que __pairs devuelve tres valores, no cuatro: no hay manera de suministrar un valor de cierre por esta vía, así que un recorrido personalizado que abra recursos debe exponerse como función propia y no colgarse de pairs. El segundo es que next no consulta el metamétodo: escribir for k in next, vista do esquiva la personalización por completo y ve la tabla real, que aquí está vacía.

Ese segundo detalle es también la objeción de fondo. Instalar __pairs significa que dos formas de recorrer el mismo valor dan resultados distintos, y que cualquier herramienta escrita por otros —un serializador, un comparador estructural, un inspector de depuración— verá una cosa o la otra según qué haya usado su autor. La tabla pasa a tener dos verdades.

Iteradores con corrutinas

Un recorrido recursivo escrito como iterador con estado obliga a aplanar la recursión en una pila explícita, y el resultado se aleja tanto del algoritmo original que a menudo deja de ser legible. La corrutina elimina ese trabajo: se escribe el recorrido de la forma natural, se emite cada elemento con una suspensión y alguien fuera lo consume.

local function enOrden(nodo)
  if nodo == nil then return end
  enOrden(nodo.izq)
  coroutine.yield(nodo.valor)     -- suspende en mitad de la recursion
  enOrden(nodo.der)
end

local function valores(raiz)
  return coroutine.wrap(function() enOrden(raiz) end)
end

for v in valores(arbol) do print(v) end

La función que devuelve coroutine.wrap cumple el protocolo sin adaptador: se llama sin argumentos útiles, devuelve lo que la corrutina emita y devuelve nulo cuando el cuerpo termina. Es un iterador con estado llevado al extremo, porque su historia no son unos upvalues sino una pila de llamadas completa, y por eso puede suspenderse a cinco niveles de profundidad, cosa que ningún closure puede hacer.

El precio tiene dos partes. La primera es la memoria: cada corrutina reserva su propia pila, mucho más que un closure. La segunda es el cambio de contexto, dos por vuelta, que aunque en Lua es notablemente barato no es comparable a una llamada ordinaria. Y hay un tercer coste que no se ve: una corrutina abandonada a medias queda suspendida, viva y reteniendo todo lo que su pila referencia hasta que el recolector la alcance.

local function valoresSeguros(raiz)
  local co = coroutine.create(function() enOrden(raiz) end)
  local guardia = setmetatable({}, {
    __close = function() coroutine.close(co) end,
  })
  return function()
    local ok, v = coroutine.resume(co)
    if not ok then error(v, 0) end
    return v
  end, nil, nil, guardia            -- el cuarto valor cierra la corrutina
end

Esta versión es la profesional. Usa la corrutina explícita en lugar de la envoltura, propaga los errores conservando el mensaje original y aprovecha el cuarto valor del protocolo para cerrar la corrutina al salir del bucle, incluso con break o con un error, liberando sus variables de cierre pendientes de inmediato.

Componer iteradores

La composición es la técnica que más rendimiento da por línea escrita, y no necesita nada nuevo. Un filtro es una función que recibe una tripleta y devuelve otra que entrega solo los elementos que pasan una condición.

local function filtrar(pred, f, s, ctrl)
  return function()
    while true do
      local k, v = f(s, ctrl)
      if k == nil then return nil end
      ctrl = k                       -- el filtro mantiene su propio control
      if pred(k, v) then return k, v end
    end
  end
end

local function transformar(fn, f, s, ctrl)
  return function()
    local k, v = f(s, ctrl)
    if k == nil then return nil end
    ctrl = k
    return k, fn(k, v)
  end
end

El detalle elegante es cómo se invocan. Como pairs devuelve tres valores y una llamada en última posición se expande, la tripleta entra sola:

local caros = filtrar(function(_, v) return v.precio > 100 end, pairs(inventario))
for k, v in transformar(function(_, v) return v.precio end, caros) do
  print(k, v)
end

flowchart LR
A[Fuente pairs sobre el inventario] --> B[Filtro deja pasar los caros]
B --> C[Transformacion emite solo el precio]
C --> D[Bucle for consume una vuelta cada vez]
D --> E[Nada intermedio se materializa en memoria]

Dos propiedades merecen subrayarse. La primera es que la tubería es perezosa: no se construye ninguna tabla intermedia, cada elemento atraviesa las tres etapas antes de que el siguiente empiece, y el consumo de memoria no depende del tamaño de la fuente. La segunda es que un break en el cuerpo detiene la tubería entera al instante, porque nadie sigue tirando de la fuente. Ese modelo de tirón es lo que hace que componer sea seguro incluso sobre fuentes infinitas.

Una nota final del presente. Bajo Lua 5.5 las variables que cada etapa entrega al cuerpo son inmutables, de modo que la costumbre de normalizar la clave o el valor reasignándolos dentro del bucle deja de compilar; el sitio correcto para esa normalización es precisamente una etapa de transformación como la de arriba, que además la hace reutilizable. La regla nueva empuja, sin proponérselo, hacia el estilo compositivo.