Patrones anidados y destructuring: leer la forma de los datos

Hasta ahora los patrones han sido de un solo nivel: un constructor y sus datos ligados a nombres. Pero los datos reales llegan encajados unos dentro de otros —un resultado dentro de una opción, una lista dentro de un caso de éxito, dos estados que hay que considerar a la vez— y desmontarlos capa por capa, con un case dentro de otro case dentro de un tercero, produce el código escalonado que todos hemos escrito alguna vez y nadie disfruta leyendo. Elm no lo necesita, porque un patrón admite otro patrón en el lugar donde iría una variable, y la profundidad es libre. Conviene entender por qué esto funciona sin sintaxis adicional, y la razón es elegante: un patrón se escribe exactamente igual que se escribiría el valor que pretende casar. No es un lenguaje de consultas ni una condición disfrazada; es la misma notación de siempre, leída en la dirección contraria. Construir y deconstruir son en Elm la ida y la vuelta del mismo camino, y esta última lección del nivel trata de aprender a recorrerlo hacia atrás con soltura.

Un patrón es una forma, no una prueba

La regla que gobierna todo lo demás cabe en una frase: allí donde un patrón admite una variable, admite también otro patrón completo. De ahí sale el anidamiento sin necesidad de inventar nada.

type Respuesta
    = Pendiente
    | Terminada (Result String (List Usuario))


resumen : Respuesta -> String
resumen respuesta =
    case respuesta of
        Pendiente ->
            "Esperando"

        Terminada (Err motivo) ->
            "Fallo: " ++ motivo

        Terminada (Ok []) ->
            "Sin resultados"

        Terminada (Ok (primero :: _)) ->
            "El primero es " ++ primero.nombre

Cuatro ramas planas describen una estructura de tres niveles de profundidad. La última merece leerse despacio: Terminada (Ok (primero :: _)) casa con una respuesta terminada, que fue un éxito, cuya lista no está vacía, y liga la cabeza de esa lista al nombre primero, todo en un solo patrón. Tres preguntas y una extracción en una línea que no contiene ni un condicional.

El operador :: es el constructor de listas, y por eso funciona también como patrón: una lista es la vacía o es un elemento seguido de otra lista. Esa doble vida —constructor cuando construyes, patrón cuando desmontas— confirma la simetría de la que hablábamos, y tiene un efecto práctico notable. List.head devuelve un Maybe porque una lista cualquiera puede estar vacía; el patrón primero :: resto, en cambio, ya ha descartado ese caso al casar, de modo que dentro de la rama primero es un Usuario de verdad y no una opción que haya que abrir otra vez.

Decidir con varios valores a la vez

El anidamiento resuelve la profundidad; las tuplas resuelven la anchura. Cuando una decisión depende de dos o tres valores simultáneamente, el impulso habitual es encadenar condicionales cruzados, y ahí es donde nacen los olvidos, porque nada obliga a considerar todas las combinaciones. Un case sobre una tupla las obliga.

type Conexion
    = EnLinea
    | SinRed


type Sesion
    = Autenticado Usuario
    | Anonimo


accion : Conexion -> Sesion -> String
accion conexion sesion =
    case ( conexion, sesion ) of
        ( EnLinea, Autenticado usuario ) ->
            "Sincronizando los datos de " ++ usuario.nombre

        ( EnLinea, Anonimo ) ->
            "Mostrando el formulario de acceso"

        ( SinRed, Autenticado _ ) ->
            "Trabajando con la copia local"

        ( SinRed, Anonimo ) ->
            "Sin red y sin sesion: solo lectura"

Lo que antes era una cascada de condiciones anidadas se ha convertido en una tabla de decisión de cuatro filas que se lee de un vistazo, y a la que el compilador aplica su cuenta habitual: dos por dos son cuatro combinaciones, y si escribes tres, no compila. La ganancia no es de brevedad sino de completitud. Con condicionales, la combinación olvidada cae silenciosamente en el else de alguien; con tuplas, la combinación olvidada es un error de compilación con nombre y apellidos.

flowchart TD
P[Patron compuesto] --> A[Anidamiento en profundidad]
P --> B[Tupla en anchura]
A --> C[Un solo case en lugar de tres encajados]
B --> D[Tabla de decision con todas las combinaciones]
C --> E[Exhaustividad verificada en todo el arbol]
D --> E
style P fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b

Destructurar fuera del case

El pattern matching no es exclusivo de case. Cualquier sitio donde Elm espera un nombre acepta en realidad un patrón, siempre que ese patrón sea irrefutable, es decir, que no pueda fallar porque el tipo solo admite una forma. Los record y las tuplas cumplen esa condición, y por eso se pueden desmontar en los argumentos de una función o en un let.

-- Destructuring en el argumento: entra un record, salen sus campos
saludo : { a | nombre : String, edad : Int } -> String
saludo { nombre, edad } =
    nombre ++ " tiene " ++ String.fromInt edad


-- Destructuring en let, con tuplas y con alias
distancia : ( Float, Float ) -> ( Float, Float ) -> Float
distancia origen destino =
    let
        ( x1, y1 ) =
            origen

        ( x2, y2 ) =
            destino
    in
    sqrt ((x2 - x1) ^ 2 + (y2 - y1) ^ 2)

El patrón de record casa por nombre de campo y no por posición, con lo que el orden en que escribas los campos da igual y solo mencionas los que vas a usar. La sintaxis { nombre, edad } liga dos variables con esos nombres, y el resto del record sigue ahí aunque no lo nombres.

Queda el alias, que resuelve una molestia frecuente. A veces necesitas las partes y también el todo, y sin él acabarías reconstruyendo con las manos el valor que acababas de desarmar. La palabra as permite tener ambos.

-- El alias da nombre al valor completo sin renunciar a sus partes
primeroYLista : List Usuario -> String
primeroYLista lista =
    case lista of
        [] ->
            "Vacia"

        (primero :: _) as completa ->
            primero.nombre
                ++ " encabeza una lista de "
                ++ String.fromInt (List.length completa)