El problema del callback

La asincronía no es difícil para la máquina. Un procesador que emite una petición de red y atiende otra cosa mientras llega la respuesta está haciendo algo perfectamente natural para él, y el sistema operativo lleva décadas ofreciendo primitivas para expresarlo. La dificultad es nuestra, y es de naturaleza lingüística: los lenguajes que usamos codifican el orden temporal en el orden textual de las instrucciones, y esa correspondencia se rompe en el instante exacto en que una operación deja de entregar su resultado por retorno. Todo lo que viene después en este nivel, incluido el bytecode que el compilador fabrica y el valor centinela que devuelve una función suspendida, es la respuesta técnica a esta única fractura. Conviene por tanto medirla con cuidado antes de estudiar la reparación, porque quien no ha visto de cerca el daño tiende a interpretar la solución como una comodidad sintáctica en lugar de como lo que realmente es: una reconstrucción del mecanismo de retorno.

Lo que la pila guardaba por nosotros

Cuando una función llama a otra de forma ordinaria, la máquina apila un marco con los parámetros, las variables locales y, sobre todo, la dirección de retorno. Esa dirección es la respuesta a la pregunta más importante del modelo de ejecución: qué hay que hacer cuando esto termine. El programador nunca la escribe porque el compilador la deduce del orden de las líneas, y esa deducción automática es el servicio que la pila presta y que damos por descontado.

fun perfilCompleto(id: String): Perfil {
    val usuario = cargarUsuario(id)          // 1
    val avatar = cargarAvatar(usuario.foto)  // 2, sabe volver aqui
    return Perfil(usuario, avatar)           // 3
}

El problema aparece cuando la operación no puede terminar ahora. Si cargarUsuario emite una petición de red y su resultado tardará doscientos milisegundos, solo hay dos salidas. La primera es dejar el marco de pila ocupado y detener el hilo hasta que llegue la respuesta, lo cual conserva la escritura secuencial al precio de inmovilizar un recurso caro. La segunda es liberar el hilo, y para eso hay que retornar; pero retornar significa destruir el marco, y destruir el marco significa que la información de qué hacer después desaparece. Si queremos conservarla tenemos que escribirla nosotros, y la única forma que un lenguaje sin soporte especial ofrece para escribir lo que hay que hacer después es pasar una función.

flowchart TD
A[Llamada ordinaria] --> B[Marco en la pila con direccion de retorno]
B --> C[La maquina sabe volver sola]
D[Llamada asincrona] --> E[El marco se destruye al retornar]
E --> F[Hay que pasar a mano lo que sigue]
F --> G[Callback]

Esa función es el callback, y conviene fijar desde ya su naturaleza exacta porque de ella depende todo el nivel: un callback no es un mecanismo de notificación ni un patrón de diseño de la programación por eventos. Un callback es la dirección de retorno convertida en un valor de primera clase. Lo que la máquina guardaba implícitamente en una ranura de la pila pasa a ser un objeto que nosotros creamos, nombramos y transportamos a mano.

La pirámide y sus tres pérdidas

La consecuencia inmediata de escribir a mano lo que la pila hacía sola es el anidamiento. Cada operación asíncrona introduce un nivel de bloque, porque todo lo que sigue debe estar dentro del callback de lo anterior. Con dos operaciones el resultado es tolerable; con cinco, el código se lee en diagonal y ya nadie sabe cuál es su forma.

fun perfilCompleto(id: String, alTerminar: (Perfil) -> Unit) {
    cargarUsuario(id) { usuario ->
        cargarAvatar(usuario.foto) { avatar ->
            cargarAmigos(usuario.id) { amigos ->
                alTerminar(Perfil(usuario, avatar, amigos))
            }
        }
    }
}

El anidamiento es el síntoma visible y el menos grave, porque la sangría se puede aplanar extrayendo funciones con nombre. Lo que no se puede aplanar son las tres capacidades que se pierden por debajo, y que no son cuestión de estética sino de expresividad del lenguaje.

Conviene además notar lo que le ha ocurrido a la firma. La función original devolvía un Perfil y podía fallar lanzando una excepción, y ambas cosas estaban escritas en su declaración o eran verificables por el compilador. La versión con callback devuelve Unit, es decir, declara que no produce nada, y esconde su resultado dentro del tipo de un parámetro. Cualquiera que lea la firma ya no sabe qué hace la función sin leer su cuerpo, y el sistema de tipos ha dejado de poder garantizar que el resultado se use, que se use una sola vez o que se use en algún momento.

La primera pérdida se ve con especial crudeza al intentar recorrer una colección. Un bucle ordinario funciona porque cada vuelta termina antes de que empiece la siguiente, y esa garantía desaparece en cuanto el cuerpo contiene una operación que devuelve su resultado más tarde. La reescritura obligada convierte el índice en un parámetro y el avance en una llamada hecha desde dentro del propio callback.

fun cargarTodos(ids: List<String>, alTerminar: (List<Usuario>) -> Unit) {
    val acumulado = mutableListOf<Usuario>()
    fun paso(i: Int) {
        if (i == ids.size) return alTerminar(acumulado)
        cargarUsuario(ids[i]) { u ->
            acumulado += u
            paso(i + 1)          // el bucle se ha vuelto una recursion
        }
    }
    paso(0)
}

La segunda pérdida merece verse escrita porque suele subestimarse. En un flujo secuencial el manejo de errores es una construcción del lenguaje que abarca una región de código con independencia de cuántas llamadas contenga; en el estilo de callbacks es un parámetro más que cada función debe declarar, que cada implementación debe recordar invocar y que cada llamante debe propagar hacia arriba a mano.

fun perfilCompleto(
    id: String,
    alTerminar: (Perfil) -> Unit,
    alFallar: (Throwable) -> Unit,
) {
    cargarUsuario(id, { usuario ->
        cargarAvatar(usuario.foto, { avatar ->
            alTerminar(Perfil(usuario, avatar))
        }, alFallar)          // hay que reenviarlo, y nadie obliga a hacerlo
    }, alFallar)
}

Continuaciones: el nombre técnico de lo que pasamos

Existe un término preciso para el objeto que un callback representa. La continuación de un punto de un programa es la totalidad del cómputo que queda por hacer a partir de ese punto: en el ejemplo inicial, la continuación de la llamada a cargarUsuario es cargar el avatar, construir el perfil y devolverlo. Es un concepto que en la ejecución ordinaria permanece implícito, disperso entre la dirección de retorno y el contenido de los marcos apilados.

Un callback hace explícito ese concepto. Cuando escribimos cargarUsuario(id) { usuario -> ... } estamos tomando la continuación de esa llamada y convirtiéndola en un objeto que se pasa como argumento. A la disciplina de escribir programas donde toda función recibe su continuación en lugar de retornar se le llama estilo de paso de continuaciones, y su propiedad característica es que ninguna función retorna nunca de verdad: todas terminan invocando a otra.

// Estilo directo: el resultado sale por retorno
fun sumar(a: Int, b: Int): Int = a + b

// Estilo de paso de continuaciones: el resultado sale por parametro
fun sumarCps(a: Int, b: Int, k: (Int) -> Unit): Unit = k(a + b)

Este ejemplo, deliberadamente trivial, contiene la observación que abre el resto del nivel. La transformación entre ambas formas es puramente mecánica: se añade un parámetro, se cambia el tipo de retorno y se sustituye cada return por una llamada a ese parámetro. Cualquier cosa mecánica puede hacerla un compilador, y ese es exactamente el punto de partida del diseño de las corrutinas de Kotlin. No se trata de darnos una librería que oculte los callbacks tras una fachada, sino de que el compilador escriba por nosotros el estilo de paso de continuaciones, de la misma forma que ya escribía por nosotros el manejo de la pila.

Lo que querríamos escribir

El objetivo, formulado con exactitud, no es eliminar los callbacks: es dejar de escribirlos. Queremos que el orden textual vuelva a ser el orden temporal, que try vuelva a cubrir todo lo que hay dentro de sus llaves, que un for pueda contener una operación que tarda, y que nada de eso obligue a inmovilizar un hilo mientras se espera.

suspend fun perfilCompleto(id: String): Perfil {
    val usuario = cargarUsuario(id)
    val avatar = cargarAvatar(usuario.foto)
    return Perfil(usuario, avatar)
}

Esa función tiene exactamente la forma de la primera versión de esta lección, con una sola palabra de diferencia, y sin embargo no bloquea ningún hilo en ninguna de sus dos esperas. La pregunta que gobierna las cuatro lecciones siguientes es cómo puede ser eso cierto, y la respuesta no está en ninguna librería ni en ningún planificador oculto: está en el código que el compilador genera a partir de ese texto. La palabra suspend no describe un comportamiento del programa en ejecución, describe una transformación que ocurre antes, y es esa transformación la que vamos a leer.