`pairs` e `ipairs`: qué devuelve realmente cada uno

Las dos funciones que todo el mundo escribe a diario son también las dos peor entendidas de la biblioteca básica, y la razón es que su nombre sugiere una acción —recorrer— que no realizan. Ni pairs ni ipairs recorren tabla alguna: ambas se limitan a devolver los tres valores que el for genérico necesita y a desaparecer del mapa antes de la primera vuelta. Toda la conducta observable del bucle, incluidas las dos preguntas que más veces se hacen en cualquier foro de Lua —por qué el orden cambia y por qué el recorrido se detiene antes de tiempo— está determinada por esos tres valores y por nada más. Esta lección abre las dos funciones, presenta a next como el iterador primitivo del que todo cuelga, y explica por qué la indefinición del orden no es un descuido de la implementación sino una consecuencia inevitable de cómo se guarda una tabla.

pairs devuelve next, la tabla y nulo

La definición completa de pairs, sin metatablas de por medio, cabe en una línea de Lua:

local function pairs(t)
  return next, t, nil
end

Eso es todo. La función iteradora es next, el estado invariante es la tabla y la variable de control inicial es nulo. La expansión de la lección anterior hace el resto: llama a next(t, nil) para obtener el primer par, guarda la clave devuelta como nuevo control, llama a next(t, clave) para el siguiente, y termina cuando next devuelve nulo.

next es una función de la biblioteca básica con un contrato preciso. Recibe una tabla y una clave presente en ella, y devuelve la siguiente clave junto con su valor, en un orden no especificado; recibiendo nulo devuelve el primer par; y devuelve nulo cuando ya no quedan claves. Consultarla con una clave que no está en la tabla es un error.

local t = { a = 1, b = 2 }
print(next(t))            -- primer par, en el orden que decida la tabla
print(next(t, "a"))       -- el par que sigue a la clave a
print(next({}))           -- nil, la tabla vacia no tiene primer par

Que pairs sea trivial tiene una consecuencia práctica que conviene interiorizar: no cuesta nada. La creencia de que pairs es más lenta que ipairs porque construye algo es falsa; lo que cuesta es next, que en cada llamada debe localizar la posición de la clave recibida y avanzar hasta la siguiente ranura ocupada.

Por qué el orden es indefinido

La tabla de Lua tiene dos mitades: una parte de vector para las claves enteras densas y una parte de dispersión para todo lo demás. next recorre primero la parte de vector en orden de índice y luego la parte de dispersión en orden de ranura física, que es donde entra el azar.

La posición de una clave en la parte de dispersión depende de su valor de dispersión, del tamaño actual del vector interno y de las colisiones que hubo mientras se insertaba. Ninguno de esos tres factores es una propiedad del programa: el tamaño cambia con los rehashes, y el valor de dispersión de una cadena depende de una semilla que las versiones modernas de Lua aleatorizan al arrancar el estado precisamente para dificultar los ataques por colisiones.

flowchart TD
A[Llamada a next con una clave] --> B[Localizar la clave en la tabla]
B --> C[Si esta en la parte de vector avanzar al siguiente indice ocupado]
B --> D[Si esta en la parte de dispersion avanzar a la siguiente ranura ocupada]
C --> E[Al agotar el vector continuar por la parte de dispersion]
D --> F[Al agotar las ranuras devolver nil]
E --> D

De ahí se sigue algo más fuerte que el orden no está garantizado: dos ejecuciones del mismo programa sobre la misma tabla pueden producir órdenes distintos, y dos tablas con las mismas claves insertadas en distinto orden casi con seguridad los producirán. Cualquier código que dependa del orden de pairs es correcto por accidente, y la forma de dejar de depender de él es recoger las claves, ordenarlas con un criterio explícito y recorrer esa lista.

ipairs fabrica un contador y para en el primer hueco

ipairs no usa next ni recorre la tabla: cuenta. Su equivalente en Lua es igual de corto y explica todo lo que hace:

local function iterador(t, i)
  i = i + 1
  local v = t[i]
  if v ~= nil then return i, v end
end

local function ipairs(t)
  return iterador, t, 0
end

La variable de control es un entero que empieza en cero, y cada vuelta pregunta por el índice siguiente. Cuando la consulta devuelve nulo, el iterador no devuelve nada, el primer valor recogido por el bucle es nulo y el recorrido termina. De ahí las dos propiedades más citadas: el orden sí está garantizado, porque los índices se generan en sucesión, y el recorrido se detiene en el primer agujero, porque la ausencia de un índice es indistinguible del final de la secuencia.

local t = { 10, 20, nil, 40 }
for i, v in ipairs(t) do print(i, v) end   -- imprime 1 y 2, y se detiene

Que esto sea un defecto o una virtud depende de la disciplina del programa. Si la tabla es una secuencia sin huecos —el contrato habitual—, ipairs es el recorrido correcto y su parada es exactamente el final. Si la tabla tiene huecos, no hay recorrido correcto posible, porque ni siquiera el operador de longitud está definido en ese caso; el problema es la estructura, no la función.

Conviene añadir la nota del presente: bajo Lua 5.5 las variables que ambos recorridos entregan al cuerpo son inmutables, de modo que el viejo hábito de reasignar la clave o el índice dentro del bucle deja de compilar. En el caso de ipairs el cambio es especialmente saludable, porque reasignar el índice dentro del cuerpo nunca alteró el conteo y sin embargo aparentaba hacerlo.

Elegir con criterio

Las tres formas habituales de recorrer una tabla no son intercambiables, y la elección se decide por lo que garantiza cada una, no por su velocidad relativa.

La lectura práctica es sencilla. Si la estructura es un diccionario, pairs es la única opción, y si además el orden importa hay que recoger las claves y ordenarlas explícitamente. Si es una secuencia sin huecos, ipairs expresa esa intención y se detiene sola donde debe. Y el for numérico solo aporta algo cuando necesitas el índice para algo más que leer el elemento —recorrer al revés, saltar de dos en dos, escribir mientras recorres— o cuando quieres distinguir un hueco de un final, porque a diferencia de ipairs te entregará el nulo en lugar de callarse.

Queda un caso que confunde a mucha gente: contar entradas. El operador de longitud no cuenta, informa de un borde de secuencia, y en una tabla con claves de cadena vale cero por definición. Contar exige recorrer con pairs y sumar, y el hecho de que no exista una función de biblioteca que lo haga no es un olvido: es la misma decisión de siempre, ya que mantener un contador actualizado encarecería toda inserción y todo borrado de todas las tablas del programa.