Records: definirlos, acceder a sus campos y el accesor que viaja solo

Todo lenguaje necesita una manera de decir que un dato tiene partes y que esas partes tienen nombre. La familia de la orientación a objetos resolvió el problema con la clase, que junta en un mismo recinto los datos y las operaciones que los tocan; la familia de los lenguajes dinámicos lo resolvió con el diccionario, que admite cualquier clave en cualquier momento y no promete nada. Elm elige un camino más antiguo y más austero: el record, una colección de campos con nombre y tipo, fijada en el instante de su creación, sin comportamiento adjunto, sin herencia, sin campos privados y sin manera alguna de cambiar lo que contiene. Un record no es un objeto pequeño ni un diccionario tipado. Es un producto cartesiano con etiquetas, la contraparte exacta de lo que en el nivel anterior era la unión etiquetada: si el custom type modela una elección entre alternativas, el record modela una conjunción de datos que se dan a la vez. Este nivel entero trata del segundo caso, y esta primera lección se ocupa del cimiento: cómo se declara un record, cómo se leen sus campos y por qué el punto que se usa para leerlos esconde una función suelta que puede pasarse de mano en mano.

Declarar: campos con nombre, tipos fijos y ninguna sorpresa

Un record se escribe entre llaves, con pares de campo e igual y valor, separados por comas. La convención de la comunidad coloca las comas al principio de cada línea, y aunque parezca una excentricidad tipográfica tiene una razón práctica: añadir o quitar un campo toca una sola línea y los diffs quedan limpios. El tipo de un record se escribe igual, sustituyendo el valor por su tipo.

-- Un record literal, con la convencion de comas por delante
ada =
    { nombre = "Ada"
    , edad = 36
    , activo = True
    }

-- Su tipo, escrito de forma anonima
firma : { nombre : String, edad : Int, activo : Bool } -> String
firma u =
    u.nombre

-- Y el mismo tipo, abreviado con un alias
type alias Usuario =
    { nombre : String
    , edad : Int
    , activo : Bool
    }

Lo primero que conviene fijar es que el record existe sin necesidad de alias: el tipo anónimo es un tipo perfectamente legítimo y el compilador lo maneja igual de bien. El alias no crea nada, solo evita escribir la forma completa cada vez. Lo segundo es que un record es cerrado en el sentido más fuerte: sus campos quedan determinados en el momento de construirlo y no existe operación alguna que añada uno nuevo, elimine uno existente o cambie el tipo de ninguno. No hay campos opcionales, no hay claves dinámicas y no hay manera de preguntar en tiempo de ejecución qué campos tiene un valor.

El punto que no es un método y el accesor que viaja solo

Leer un campo se escribe con un punto, y esa notación es la única del lenguaje que parece importada de la orientación a objetos. No lo es. Aquí el punto no invoca nada ni resuelve nada en tiempo de ejecución: es una operación de proyección que el compilador conoce por completo. La prueba está en que Elm define además el accesor suelto, es decir, un punto seguido del nombre del campo que constituye por sí mismo una función.

-- Las dos formas son equivalentes
ada.nombre          -- "Ada"
.nombre ada         -- "Ada"

-- El accesor suelto es una funcion y por tanto se pasa como argumento
nombres : List Usuario -> List String
nombres =
    List.map .nombre

-- Su firma es polimorfica gracias a la variable de fila
-- .nombre : { a | nombre : b } -> b

mayoresDeEdad : List Usuario -> List Usuario
mayoresDeEdad =
    List.filter (\u -> u.edad >= 18)

-- Y se compone como cualquier otra funcion
inicial : Usuario -> String
inicial =
    .nombre >> String.left 1

La firma del accesor merece una lectura pausada. Dice que acepta cualquier record que tenga al menos un campo llamado nombre, de un tipo cualquiera, y devuelve exactamente ese tipo. La letra que precede a la barra representa el resto de campos, sean los que sean, y por eso el mismo accesor sirve para un Usuario, para un Producto y para cualquier forma futura que tenga un campo con ese nombre. Es polimorfismo estructural puro, resuelto en compilación y sin coste en tiempo de ejecución.

flowchart LR
R[Record con campos] --> P[Punto de acceso]
R --> A[Accesor suelto como funcion]
P --> V[Valor del campo]
A --> M[Argumento de List map]
M --> L[Lista de valores]
style A fill:#cba6f7,color:#11111b
style V fill:#a6e3a1,color:#11111b
style L fill:#89b4fa,color:#11111b

Estructural, no nominal: la forma es la identidad

La propiedad más consecuente del sistema de records de Elm es que su tipado es estructural. Un record no pertenece a una clase ni recuerda de dónde salió: es su forma y nada más. Dos alias distintos que describan los mismos campos con los mismos tipos nombran, literalmente, el mismo tipo, y el compilador permite intercambiarlos sin conversión ni advertencia alguna.

-- Dos nombres, un unico tipo: son intercambiables
type alias Punto2D = { x : Float, y : Float }
type alias Vector2D = { x : Float, y : Float }

sumar : Punto2D -> Vector2D -> Punto2D
sumar p v =
    { x = p.x + v.x, y = p.y + v.y }

-- Para que el compilador los distinga hace falta un custom type
type Metros
    = Metros Float

type Segundos
    = Segundos Float

La consecuencia práctica es que el record es excelente para agrupar y pésimo para distinguir. Agrupar es su trabajo: reúne partes relacionadas bajo un nombre y las hace viajar juntas. Distinguir requiere otra herramienta, porque ninguna cantidad de alias creará una frontera que el compilador esté dispuesto a defender.

Hay además una asimetría que conviene fijar desde ahora porque atraviesa el nivel entero. El record es un tipo producto: contiene un valor de cada uno de sus campos, todos a la vez, y el número de valores distintos que puede representar es el producto de las posibilidades de cada campo. El custom type que estudiaste en el nivel anterior es un tipo suma: contiene un valor de una de sus variantes, y sus posibilidades se suman en lugar de multiplicarse. Esa diferencia aritmética, que parece un juego, resultará ser la herramienta de diagnóstico más útil al diseñar el modelo de una aplicación, porque un producto demasiado ancho es exactamente lo que permite representar situaciones que el dominio prohíbe.