type: la unión etiquetada como herramienta de modelado

Hasta ahora todos los tipos que has construido en Elm han respondido a la conjunción. Un record con tres campos dice: hay un número y un texto y un booleano. Una tupla dice lo mismo con menos ceremonia. Son tipos producto, y ese nombre no es una metáfora poética sino una cuenta exacta que veremos al final. Pero la mitad del modelado del mundo no es conjuntiva sino disyuntiva. Un pago es con tarjeta o por transferencia o en efectivo. Una petición está pendiente o ha terminado bien o ha fallado. Una figura es un círculo o un rectángulo. Esa segunda mitad —el o exclusivo, la alternativa cerrada— no cabe en un record, y forzarla a caber produce exactamente los diseños defectuosos que este nivel viene a desmontar. La palabra clave type es la respuesta de Elm: declara un tipo nuevo cuyos valores son exactamente las alternativas que enumeras, cada una marcada con una etiqueta que la separa sin ambigüedad de las demás. Se llama unión etiquetada, o tipo suma, y es sin exageración la herramienta de modelado más importante del lenguaje.

El eje que faltaba: de la conjunción a la disyunción

Un record combina información: para tener un valor necesitas todos sus campos a la vez. Un tipo suma hace lo contrario: para tener un valor basta con uno de sus casos, y solo uno. Son los dos ejes ortogonales del modelado de datos, y cualquier estructura que sepas describir se compone de ellos en alguna proporción. Elm te dio el primero desde el principio; el segundo llega con type.

-- Producto: hay un nombre Y una edad Y un correo, todos a la vez
type alias Usuario =
    { nombre : String
    , edad : Int
    , correo : String
    }


-- Suma: es exactamente uno de estos tres casos, nunca dos, nunca ninguno
type MetodoPago
    = Tarjeta
    | Transferencia
    | Efectivo

Cada nombre a la derecha del = y de las barras verticales es un constructor. Un constructor cumple dos funciones simultáneas que conviene no confundir: es la etiqueta que discrimina el caso y es, él mismo, un valor del tipo. Escribir Tarjeta no llama a nada ni ejecuta nada; produce un valor de tipo MetodoPago cuya única propiedad interesante es ser distinguible de Transferencia y de Efectivo. No hay un número oculto detrás, ni una cadena de texto, ni un índice: la identidad del caso es la etiqueta.

Y el conjunto es cerrado. Fuera de esas tres alternativas no existe ni puede existir un cuarto valor de tipo MetodoPago; no hay forma de fabricar uno desde otro módulo, ni de convertir un String en uno por descuido, ni de que llegue uno inesperado desde el exterior. Esa clausura es lo que permitirá, en la lección tercera, que el compilador verifique que has tratado todos los casos: solo se puede exigir exhaustividad sobre un conjunto que se sabe completo.

Modelar con alternativas en lugar de con banderas

El valor práctico de los tipos suma se ve mejor por contraste, observando qué ocurre cuando no se tienen. Sin ellos, el modelador recurre a dos sustitutos pobres: banderas booleanas y cadenas de texto. Ambos comparten el mismo defecto estructural, que es admitir muchos más valores de los que el dominio tiene sentidos.

-- Antipatron: banderas independientes para estados que se excluyen
type alias Pedido =
    { enviado : Bool
    , entregado : Bool
    , cancelado : Bool
    }


-- Nada impide construir esto, y no significa absolutamente nada
absurdo : Pedido
absurdo =
    { enviado = False, entregado = True, cancelado = True }

Tres booleanos admiten ocho combinaciones. El dominio real tiene cuatro estados, y los cuatro se excluyen mutuamente. Las otras cuatro combinaciones son basura sintácticamente válida que el compilador acepta sin pestañear y que tú tendrás que defender a mano, con comprobaciones dispersas por toda la aplicación y comentarios que ruegan no poner los dos a True. La variante con String es peor todavía, porque el número de valores posibles pasa de ocho a infinito y una errata como "entregdo" es un valor perfectamente legal que ninguna herramienta detecta.

-- Modelado con alternativas: existen los cuatro estados reales y ni uno mas
type EstadoPedido
    = Recibido
    | Enviado
    | Entregado
    | Cancelado

El cambio no es cosmético. Antes tenías un tipo con ocho habitantes de los que cuatro eran mentira; ahora tienes un tipo con cuatro habitantes, todos verdaderos. La categoría entera de errores que consistía en dos banderas contradictorias ha dejado de ser un bug para pasar a ser algo que no se puede ni escribir. Y como el conjunto es cerrado y nombrado, la definición se lee como documentación que el compilador mantiene honesta: quien abra el archivo dentro de un año sabrá en cuatro líneas qué le puede pasar a un pedido.

flowchart TD
T[type EstadoPedido] --> A[Recibido]
T --> B[Enviado]
T --> C[Entregado]
T --> D[Cancelado]
A --> U[Un valor es exactamente uno de los cuatro]
B --> U
C --> U
D --> U
style T fill:#f9e2af,color:#11111b
style U fill:#a6e3a1,color:#11111b

Los dos ejes no compiten entre sí; se anidan. Un tipo suma puede tener variantes que lleven productos dentro, y un producto puede tener campos cuyo tipo sea una suma. El modelado real alterna ambos según lo que el dominio pida en cada nivel, y saber en cuál de los dos ejes estás en cada momento es buena parte del oficio.

-- Suma en el nivel exterior, producto dentro de una de sus variantes
type Sesion
    = Anonima
    | Iniciada Credenciales


type alias Credenciales =
    { usuario : String
    , caducidad : Int
    }

Un String de usuario y una caducidad solo tienen sentido cuando la sesión está iniciada, y por eso viven dentro de esa variante y no al lado de ella. Si estuvieran sueltos en un record junto a una bandera, el tipo permitiría una sesión anónima con credenciales, que es literalmente una contradicción. Colocar cada dato en el nivel correcto del anidamiento es la operación que la cuarta lección de este nivel convertirá en método.

Nombrar es modelar

Hay una consecuencia menos técnica y más profesional de todo esto. Un tipo suma obliga a nombrar cada alternativa, y nombrar obliga a decidir. Cuando escribes type EstadoPedido y empiezas a enumerar constructores, estás haciendo análisis de dominio con el compilador delante: cada caso que añades es una afirmación sobre el mundo que se puede discutir con quien conoce el negocio. Los booleanos permiten posponer ese trabajo indefinidamente, y esa comodidad inicial es justamente la trampa, porque la decisión no desaparece: se difiere y se dispersa por cien condicionales que nadie volverá a leer juntos.

El criterio de diseño que sale de aquí es sencillo de enunciar y sorprendentemente exigente de aplicar. Cada vez que estés a punto de introducir un Bool en un modelo, pregúntate qué dos situaciones representa y si de verdad son solo dos; y cada vez que introduzcas dos booleanos relacionados, sospecha en firme, porque casi siempre son una suma de tres o cuatro casos disfrazada. La sospecha se generaliza: un String que solo debería tomar ciertos valores, un Int que codifica un estado, un campo llamado tipo o modo son todos síntomas del mismo hueco, que es una unión etiquetada que alguien no pudo o no quiso declarar.