Los ocho tipos: el inventario cerrado de Lua

Casi todos los lenguajes que has usado responden a la pregunta «cuántos tipos hay» con una lista abierta que crece cada vez que alguien declara una clase. Lua responde con una lista cerrada de ocho entradas que lleva dos décadas sin moverse y que no puedes ampliar desde el propio lenguaje: nil, boolean, number, string, table, function, userdata y thread. Todo lo demás —objetos, clases, módulos, colas, conjuntos, excepciones— se construye encima, casi siempre con tablas. Aprender esta lista no es memorizar ocho palabras: es entender qué decidieron los diseñadores no incluir, y por qué esa ausencia es la fuente de la flexibilidad de Lua.

El inventario cerrado

Esta lista es cerrada en un sentido fuerte: no existe ninguna construcción del lenguaje que produzca un valor cuyo tipo esté fuera de ella. Cuando escribes lo que parece una clase, estás creando una tabla; cuando escribes lo que parece un objeto, estás creando otra tabla enlazada a la primera. La consecuencia práctica es que el vocabulario semántico de Lua es minúsculo, y todo el poder expresivo se desplaza a un solo tipo, la tabla, y a un solo mecanismo de extensión, las metatablas.

flowchart TD
V[Todo valor de Lua] --> A[Semantica de valor]
V --> B[Semantica de referencia]
A --> A1[nil]
A --> A2[boolean]
A --> A3[number]
A --> A4[string]
B --> B1[table]
B --> B2[function]
B --> B3[userdata]
B --> B4[thread]
style A fill:#a6e3a1,color:#11111b
style B fill:#89b4fa,color:#11111b

Esa división en dos columnas no es decorativa y volverá en la cuarta lección de este nivel: los cuatro tipos de la izquierda se copian al asignarse, los cuatro de la derecha se comparten.

La función type y lo que devuelve de verdad

type acepta cualquier valor y devuelve una cadena. Este detalle, que parece anecdótico, gobierna la forma de todo el código defensivo que escribirás en Lua.

print(type(nil))                  --> nil        (la cadena, no el valor)
print(type(true))                 --> boolean
print(type(10))                   --> number
print(type("10"))                 --> string
print(type({}))                   --> table
print(type(print))                --> function
print(type(io.stdout))            --> userdata
print(type(coroutine.create(print))) --> thread
print(type(type))                 --> function

Como el resultado es una cadena, la comprobación de tipos se hace comparando cadenas, y ahí aparece el error más silencioso del principiante: una errata en el literal no produce ningún fallo, solo una condición que nunca se cumple.

local function esTabla(v)
  return type(v) == "tabla"   -- errata: siempre false, nunca avisa
end

No hay defensa del lenguaje contra esto porque, para Lua, "tabla" es una cadena tan legítima como "table". La disciplina práctica consiste en no esparcir literales de tipo por el código: centralizarlos en una función de validación o en una tabla de constantes, de forma que la errata exista en un solo lugar y sea localizable.

Conviene además saber qué no distingue type. No separa el entero del flotante, no separa el userdata ligero del completo, y no dice nada sobre la metatabla del valor. Dos tablas que representan conceptos completamente distintos son ambas "table". Si necesitas una noción de clase, tendrás que fabricarla tú, normalmente guardando un campo identificador o comparando metatablas con getmetatable.

Las variables no tienen tipo, los valores sí

En Lua no se declara el tipo de una variable porque la variable no es el sitio donde vive el tipo. Una variable es un nombre asociado a una ranura que puede contener cualquier valor, y el tipo viaja dentro del valor, no en la ranura. Esa es la razón de que el siguiente código sea perfectamente legal y no genere ni un aviso.

local x = 42          -- ahora x contiene un number
x = "cuarenta y dos"  -- ahora contiene un string
x = { 42 }            -- ahora una table
x = print             -- ahora una function
x = nil               -- ahora nada, y el valor anterior queda recolectable

Esto se llama tipado dinámico, pero conviene precisar en qué sentido Lua es dinámico y en cuál no. Lua sí es fuertemente tipado en tiempo de ejecución: nunca reinterpreta los bits de un valor como si fuera de otro tipo, y una operación aplicada a un tipo que no la admite produce un error inmediato en lugar de un resultado basura. Lo que no hay es una fase de comprobación estática, así que el error aparece cuando la línea se ejecuta, no cuando se carga el archivo.

local t = {}
print(#t)        -- 0, la longitud de una tabla vacia
print(#true)     -- error de ejecucion: attempt to get length of a boolean value

La implicación de diseño es que, en Lua, la fiabilidad no la aporta el compilador sino las pruebas y las guardas explícitas en las fronteras de tus módulos. Escribir una validación de argumentos al principio de una función pública no es paranoia: es el sustituto directo de la firma de tipos que el lenguaje no te ofrece.

El subtipo que type no te enseña

Desde Lua 5.3 el tipo number tiene dos representaciones internas: entero de 64 bits con complemento a dos y flotante de doble precisión IEEE 754. type devuelve "number" para ambas y math.type es la función que revela cuál es cuál.

print(math.type(3))      --> integer
print(math.type(3.0))    --> float
print(math.type(3 / 1))  --> float   (la division siempre produce float)
print(math.type("3"))    --> nil     (no es un numero, es una cadena)
print(3 == 3.0)          --> true    (iguales como valores matematicos)

Que 3 y 3.0 sean iguales pero de subtipo distinto tiene efectos observables en tres sitios concretos: la representación textual, donde tostring produce 3 frente a 3.0; el desbordamiento, porque los enteros dan la vuelta en silencio mientras los flotantes se van a infinito; y las operaciones que exigen representación entera, como los operadores de bits, los índices de string.sub o el formato %d, que fallan con un flotante no integral.