Tipos parametrizados: el hueco que hace genérico a un tipo

Después de tres lecciones usándolos sin nombrarlos, toca poner nombre a los huecos. Cuando escribes List a no estás nombrando un tipo, estás nombrando una plantilla de tipos: List por sí solo no designa nada que pueda existir en un programa, igual que una función sin argumentos aplicados no designa un valor. Solo cuando el hueco a se rellena con algo concreto —List Int, List Usuario, List (Maybe String)— aparece un tipo del que se pueden tener valores. Esa idea, el polimorfismo paramétrico, es la que permite que la biblioteca estándar tenga una sola función map en lugar de una por cada tipo de elemento. Pero su interés no acaba en la reutilización, que es lo obvio. Lo verdaderamente notable es lo contrario de lo que uno esperaría: cuanto menos sabe una función sobre sus datos, más sabemos nosotros sobre esa función. La generalidad no diluye la información del tipo, la concentra.

Un tipo con un hueco todavía no es un tipo

La distinción sintáctica es mínima y la conceptual es enorme. Int es un tipo: existen valores suyos. List no es un tipo: no existe ningún valor cuyo tipo sea List, del mismo modo que no existe ningún número que sea la suma. List es una función a nivel de tipos, que recibe un tipo y devuelve un tipo. Se le llama constructor de tipos, y como cualquier función, hay que aplicarlo para obtener algo concreto.

-- Declarar un tipo parametrizado: la minuscula es el hueco
type Maybe a
    = Just a
    | Nothing

type Result e v
    = Ok v
    | Err e

-- Aplicar el constructor produce tipos concretos y distintos
edades : List Int
nombres : List String
matriz : List (List Float)
respuesta : Result String Usuario

Fíjate en Just. Es una función corriente cuya firma es a -> Maybe a: recibe un valor cualquiera y lo envuelve. Y en Nothing, que no recibe nada y cuyo tipo es directamente Maybe a, válido para cualquier a, porque no contiene nada que pudiera contradecir esa promesa. Los constructores de las variantes son valores del lenguaje, mientras que los constructores de tipos viven un piso más arriba, en el nivel de los tipos. Elm mantiene esos dos pisos rigurosamente separados, y por eso no hay ambigüedad aunque los nombres se parezcan.

Lo que una firma genérica te está prohibiendo

Aquí llega el giro que separa entender el polimorfismo de haberlo entendido de verdad. Cuando una función recibe un valor de tipo a, no sabe nada sobre él: no puede sumarlo, no puede compararlo, no puede convertirlo a texto ni preguntar de qué tipo es. En Elm no existe la reflexión, así que esa ignorancia es absoluta y no hay forma de eludirla. Lo único que la función puede hacer con un valor de tipo desconocido es lo mismo que harías tú con un paquete cerrado: guardarlo, duplicarlo, descartarlo, moverlo de sitio o entregárselo a otra función que sí sepa qué hacer con él.

-- Solo hay una funcion posible con esta firma, y es la identidad
misterio : a -> a

-- Con esta hay exactamente dos: devolver siempre el primero
-- o devolver siempre el segundo
eleccion : a -> a -> a

-- Y esta es imposible de escribir sin trampas: de donde sacarias un b
imposible : a -> b

Esa observación tiene nombre técnico, parametricidad, y consecuencias sorprendentemente fuertes. La firma a -> a no admite más implementación total que devolver el argumento intacto: no hay ningún otro valor de tipo a disponible en el universo de esa función, porque no puede fabricarlo. La firma List a -> List a restringe a reordenar, repetir o descartar elementos, y jamás a inventarlos o modificarlos. Y map : (a -> b) -> List a -> List b garantiza que cada elemento de la salida procede de aplicar la función recibida a algún elemento de la entrada, porque no existe otra manera de producir un b. Leer una firma genérica es, entonces, leer una lista de imposibilidades, y esa lista suele ser más informativa que el nombre de la función.

flowchart TD
F[Firma con variable de tipo] --> P[La funcion no conoce el tipo]
P --> N1[No puede inspeccionarlo]
P --> N2[No puede fabricarlo]
P --> N3[No puede compararlo]
N1 --> G[Conjunto de implementaciones posibles muy pequeno]
N2 --> G
N3 --> G
G --> S[La firma casi determina el comportamiento]
style G fill:#89b4fa,color:#11111b
style S fill:#a6e3a1,color:#11111b

Los ejemplos concretos, uno a uno

Vale la pena recorrer las firmas polimórficas que aparecen a diario y traducir cada una a lenguaje llano, porque el hábito de hacerlo mentalmente es lo que acaba volviendo transparente la biblioteca estándar entera.

-- Transformar cada elemento: la salida se fabrica solo con la funcion dada
List.map : (a -> b) -> List a -> List b

-- Quedarse con algunos: el tipo no cambia, luego no puede modificarlos
List.filter : (a -> Bool) -> List a -> List a

-- Reducir a un solo valor acumulando de derecha a izquierda
List.foldr : (a -> b -> b) -> b -> List a -> b

-- Aplicar dentro del envoltorio sin abrirlo a mano
Maybe.map : (a -> b) -> Maybe a -> Maybe b

-- Encadenar operaciones que a su vez pueden faltar
Maybe.andThen : (a -> Maybe b) -> Maybe a -> Maybe b

-- Dos huecos independientes: el error y el valor viajan por separado
Result.map : (a -> b) -> Result e a -> Result e b

Compara las dos últimas parejas, porque su diferencia es la que más cuesta al principio. Maybe.map recibe una función que siempre devuelve un valor y la aplica dentro del envoltorio; si le dieras una función que a su vez puede fallar, obtendrías un Maybe dentro de otro Maybe, un anidamiento que no quieres. Para eso está andThen, cuya función recibida ya devuelve algo envuelto y cuyo trabajo es aplanar el resultado. Las firmas lo dicen todo sin necesidad de explicación en prosa: basta mirar dónde aparece el envoltorio en el tipo de la función que se recibe.

El polimorfismo que sostiene la arquitectura

Los tipos parametrizados no son una utilidad de la biblioteca de colecciones: son el andamio de la Arquitectura Elm. Html msg significa un fragmento de vista que, cuando el usuario interactúe con él, producirá mensajes de tipo msg. Cmd msg significa un efecto que, cuando el runtime lo ejecute, devolverá su resultado como un msg. Que el parámetro esté ahí es lo que permite escribir componentes de vista reutilizables, ajenos al mensaje concreto de la aplicación que los use, y luego adaptarlos con Html.map al conectarlos a un módulo mayor.

-- Un boton generico: sirve para cualquier aplicacion
boton : String -> msg -> Html msg
boton texto alPulsar =
    button [ onClick alPulsar ] [ text texto ]

-- Traducir los mensajes de un submodulo al del padre
Html.map : (a -> b) -> Html a -> Html b
Cmd.map : (a -> b) -> Cmd a -> Cmd b

Ese Html.map es el mismo map de siempre, con la misma forma y la misma garantía, aplicado a un constructor de tipos distinto. Cuando compones un submódulo dentro de una aplicación mayor, no necesitas un mecanismo especial de comunicación entre componentes: envuelves sus mensajes en una variante del mensaje del padre y traduces la vista con Html.map. Toda la composición modular de Elm descansa en que estos tipos tengan un hueco.