Actualización inmutable: copiar con un campo distinto y no mutar jamás

En casi cualquier lenguaje, cambiar el estado de un dato consiste en apuntar a él y sobrescribir una de sus partes. La operación es tan barata, tan universal y tan temprana en el aprendizaje de cualquiera que cuesta verla como lo que es: una decisión de diseño, y no una ley de la naturaleza. Elm la rechaza sin matices. No existe ninguna forma de modificar un record ya construido, ni siquiera dentro de la función que lo creó, ni siquiera si nadie más lo está mirando. Lo que existe en su lugar es una sintaxis que produce un valor nuevo a partir de uno viejo, cambiando lo que le digas y copiando lo demás, y que se escribe de una manera tan compacta que resulta fácil confundirla con la asignación que sustituye. Esa confusión hay que deshacerla desde el primer minuto, porque de la diferencia entre modificar y derivar cuelgan casi todas las garantías del lenguaje: la pureza de update, la posibilidad de guardar la historia entera de estados, el viaje en el tiempo del depurador y la capacidad de leer una función sabiendo que nada de lo que recibió puede haber cambiado mientras la leías.

Derivar un valor nuevo, no cambiar el viejo

La sintaxis de actualización toma un record, una barra vertical y una lista de campos con sus valores nuevos. El resultado es un record distinto: mismos campos, mismos tipos, mismo alias, y los valores que indicaste sustituidos. El original no se ve afectado de ninguna manera, sigue vivo y sigue siendo utilizable inmediatamente después.

type alias Usuario =
    { nombre : String
    , edad : Int
    , activo : Bool
    }

-- Produce un record NUEVO; ada sigue teniendo 36
cumplirAnios : Usuario -> Usuario
cumplirAnios u =
    { u | edad = u.edad + 1 }

-- Varios campos a la vez, separados por comas
renombrarYDesactivar : String -> Usuario -> Usuario
renombrarYDesactivar nuevo u =
    { u | nombre = nuevo, activo = False }

-- El original permanece intacto y ambos coexisten
ada : Usuario
ada =
    Usuario "Ada" 36 True

adaMayor : Usuario
adaMayor =
    cumplirAnios ada        -- edad 37, mientras ada sigue en 36

Es útil leer la expresión en voz alta con las palabras correctas. No dice cambia la edad de este usuario, dice dame un usuario como este pero con esta edad. La diferencia parece retórica y no lo es: en la primera lectura hay un sujeto que sufre una acción, en la segunda hay una función que devuelve un valor. Toda la Arquitectura Elm se sostiene sobre la segunda, porque update no altera el modelo que recibe, sino que construye el siguiente.

Copiar no es caro: la compartición estructural

La objeción inmediata de quien viene de un lenguaje imperativo es económica: si cada cambio produce una copia, un modelo grande costará una fortuna por cada tecla que pulse el usuario. La objeción sería correcta si la copia fuese profunda, y no lo es. Lo que se construye es un contenedor nuevo cuyos campos apuntan a los mismos valores de antes, salvo los que has cambiado. El trabajo es proporcional al número de campos del record, no al tamaño de los datos que contiene.

type alias Modelo =
    { usuarios : List Usuario     -- puede tener diez mil elementos
    , filtro : String
    , pagina : Int
    }

-- Esta actualizacion NO copia la lista de usuarios: la comparte
irAPagina : Int -> Modelo -> Modelo
irAPagina n modelo =
    { modelo | pagina = n }

El diagrama que sigue lo muestra con claridad: dos versiones del modelo coexisten, ambas apuntan a la misma lista y al mismo filtro, y solo el campo que cambió tiene un valor propio en la versión nueva. La memoria adicional que consume la segunda versión es un puñado de referencias, no una copia de los datos, y esa proporción se mantiene por muy grande que sea el contenido.

La razón por la que compartir es seguro es precisamente la inmutabilidad, y aquí las dos ideas se sostienen mutuamente. En un lenguaje con mutación, compartir una referencia es peligroso porque alguien podría escribir a través de ella y afectar a todos los que la comparten; por eso las copias defensivas son una práctica obligada y por eso son caras. Si nadie puede escribir, compartir deja de tener riesgo y la copia defensiva pierde su motivo de ser. La inmutabilidad no hace que copiar sea barato: hace que casi nunca haga falta copiar.

flowchart LR
M1[Modelo v1] --> L[Lista de usuarios]
M1 --> F1[Filtro]
M1 --> P1[Pagina 1]
M2[Modelo v2] --> L
M2 --> F1
M2 --> P2[Pagina 2]
style L fill:#a6e3a1,color:#11111b
style P2 fill:#f9e2af,color:#11111b
style M2 fill:#89b4fa,color:#11111b

Qué desaparece cuando desaparece la mutación

La ausencia de mutación no se nota tanto por lo que hay que escribir como por lo que deja de poder ocurrir. Una función que recibe un record sabe que ese record no cambiará mientras dure su ejecución, ni durante las llamadas que haga, ni después. Esa certeza es lo que permite razonar localmente sobre un fragmento de código sin conocer el programa entero.

-- Encadenar transformaciones es seguro: cada paso recibe un valor estable
procesar : Usuario -> Usuario
procesar =
    cumplirAnios
        >> renombrarYDesactivar "anonimo"

-- Guardar la historia no requiere nada especial: son valores
type alias Historial =
    { actual : Modelo
    , anteriores : List Modelo
    }

registrar : Modelo -> Historial -> Historial
registrar nuevo h =
    { actual = nuevo
    , anteriores = h.actual :: h.anteriores
    }

El bloque de historial es el ejemplo más elocuente. En un lenguaje con mutación, conservar los estados anteriores obliga a clonarlos en profundidad en cada paso, porque de lo contrario todas las entradas del historial acabarían apuntando al mismo objeto mutado y mostrarían el mismo contenido. En Elm no hay nada que clonar: cada modelo anterior es un valor, y guardar valores es lo único que el lenguaje sabe hacer. El depurador con viaje en el tiempo no es una hazaña de ingeniería, es una consecuencia trivial de esta propiedad.