Constructores con datos: cada variante lleva lo suyo

La lección anterior dejó los tipos suma a medio presentar. Tal como los vimos —constructores desnudos, meras etiquetas que se distinguen entre sí— apenas superan a un enum bien hecho, y si eso fuera todo, la unión etiquetada sería una comodidad menor y no la herramienta central que promete ser. Lo que la transforma es una capacidad que parece pequeña y no lo es: cada constructor puede transportar sus propios datos, y la carga puede ser distinta en cada variante, en tipo y en número de argumentos. Cargando no necesita llevar nada, porque no hay nada que decir salvo que se está esperando; Exito necesita llevar los datos que llegaron; Error necesita llevar el fallo, que es información de una naturaleza completamente distinta. Un solo tipo, tres variantes, tres formas de carga incompatibles entre sí, y ninguna de ellas accesible fuera del caso al que pertenece. Esa correlación entre la etiqueta y su información es la que convierte un catálogo de estados en un modelo de datos honesto.

La carga: qué acompaña a cada etiqueta

Añadir datos a un constructor consiste en escribir, tras su nombre, los tipos de sus argumentos. No hay nombres de campo ni sintaxis adicional: la posición basta, porque la variante suele llevar una o dos cosas y no un formulario entero.

type Figura
    = Circulo Float
    | Rectangulo Float Float
    | Punto


areaAproximada : Figura -> Float
areaAproximada figura =
    case figura of
        Circulo radio ->
            3.1416 * radio * radio

        Rectangulo ancho alto ->
            ancho * alto

        Punto ->
            0

Fíjate en lo que acaba de ocurrir. Circulo lleva un Float, Rectangulo lleva dos y Punto no lleva ninguno; las tres son Figura con la misma legitimidad. No hay un campo radio que sobre en el rectángulo ni un campo alto que sobre en el círculo, porque la información no vive en el tipo sino en la variante. Un rectángulo no tiene radio, ni siquiera un radio nulo o vacío: sencillamente no existe tal cosa en ese caso, y el tipo lo dice sin rodeos.

El estado de carga: el ejemplo canónico

Ningún ejemplo enseña mejor la idea que el estado de una petición remota, porque es el sitio donde casi todo el software del mundo se ha modelado mal alguna vez. La situación tiene cuatro momentos posibles y su información asociada difiere radicalmente en cada uno.

type EstadoCarga
    = Inactivo
    | Cargando
    | Exito (List Usuario)
    | Error Http.Error


type alias Model =
    { usuarios : EstadoCarga }

Los paréntesis en Exito (List Usuario) son necesarios porque List Usuario es un tipo compuesto de dos palabras y sin ellos el compilador leería dos argumentos separados. Leído en voz alta, el tipo dice: aún no se ha pedido nada, o se está esperando, o llegaron estos usuarios, o falló con este error. Y dice también, con la misma fuerza, todo lo que no puede pasar: no hay usuarios mientras se carga, no hay error cuando hay éxito, no existe el limbo de haber terminado sin datos y sin fallo.

Compáralo con el diseño que aparece cuando no se dispone de sumas o no se piensa en ellas, que consiste en aplanar todo en un record y coordinar los campos a mano.

-- Antipatron: los campos no estan correlacionados y hay que rezar
type alias ModelPlano =
    { cargando : Bool
    , usuarios : List Usuario
    , error : Maybe String
    }


-- Legal, absurdo, y el compilador no dira nada
imposible : ModelPlano
imposible =
    { cargando = True, usuarios = [ usuarioX ], error = Just "fallo" }

Ese record admite cargando y con datos y con error a la vez. Admite también no cargando, sin datos y sin error, un estado que no distingue el aún no he pedido nada del he pedido y no había resultados. La vista que lo consuma tendrá que decidir un orden de comprobaciones —¿miro primero el error o la bandera?— y ese orden es una regla no escrita que vive en la cabeza de quien lo escribió y en ningún tipo. Con EstadoCarga, la vista no comprueba nada: pregunta por el caso, y en cada rama recibe exactamente los datos que ese caso garantiza.

flowchart LR
E[EstadoCarga] --> I[Inactivo sin datos]
E --> C[Cargando sin datos]
E --> S[Exito con List Usuario]
E --> F[Error con Http Error]
S --> V[La lista solo existe dentro de esta rama]
F --> W[El error solo existe dentro de esta rama]
style E fill:#f9e2af,color:#11111b
style V fill:#a6e3a1,color:#11111b
style W fill:#f38ba8,color:#11111b

Recursión y parámetros: el mismo mecanismo, más lejos

Dos extensiones naturales aparecen sin sintaxis nueva. La primera es que un constructor puede llevar como dato un valor del tipo que se está definiendo, y eso es todo lo que hace falta para describir estructuras arbitrariamente profundas. La segunda es que el tipo puede tomar parámetros, con lo que la forma se separa del contenido y se vuelve reutilizable.

type Arbol a
    = Vacio
    | Nodo a (Arbol a) (Arbol a)


-- Los tipos mas usados de Elm no son magia del lenguaje:
-- son tipos suma normales que cualquiera podria haber escrito
type Maybe a
    = Nothing
    | Just a


type Result error valor
    = Err error
    | Ok valor

Merece detenerse un segundo en la última observación, porque reordena el mapa mental de quien viene de otros lenguajes. Maybe y Result no son construcciones privilegiadas del compilador ni palabras clave con trato especial: son declaraciones type corrientes, escritas en Elm, que usan exactamente el mecanismo que acabas de aprender. La ausencia de valor no es un agujero en el sistema de tipos sino un constructor sin datos llamado Nothing; la presencia es un constructor con datos llamado Just. Si mañana necesitas un tipo con cuatro estados de carga en lugar de dos resultados, lo escribes tú mismo con las mismas herramientas, y quedará tan integrado en el lenguaje como los que vienen de fábrica. Eso es lo que significa que la unión etiquetada sea la herramienta de modelado: no describe algunos casos previstos, describe la forma de los datos en general.