El modelo de Hewitt en serio: tres verbos y ninguna trampa

El modelo de actores cabe en una frase que casi todo el mundo repite mal: un actor puede crear actores, enviar mensajes y designar el comportamiento con el que atenderá el siguiente. Parece una lista de funcionalidades y es una lista de prohibiciones, porque lo que no aparece en ella está vetado. No hay lectura síncrona. No hay memoria común. No hay forma de dirigirse a alguien cuya dirección no te hayan entregado. No hay cota superior al tiempo que un mensaje puede tardar en llegar. Tomar esa parquedad en serio —formalizarla en vez de parafrasearla— revela que de tres verbos y un axioma de entrega se deducen propiedades que ningún modelo basado en memoria compartida puede siquiera enunciar.

El comportamiento como función total

En el modelo puro un actor no tiene estado: tiene un comportamiento. Y un comportamiento no es un objeto con campos, sino una función total que recibe un mensaje y devuelve exactamente tres cosas: un conjunto finito de mensajes a enviar, un conjunto finito de actores a crear y el comportamiento con el que se atenderá el siguiente mensaje. La firma lo dice todo mejor que cualquier párrafo.

type Direccion = symbol

type Mensaje =
  | { readonly tipo: 'incrementar' }
  | { readonly tipo: 'leer'; readonly responder: Direccion }
  | { readonly tipo: 'valor'; readonly valor: number }

type Efecto = {
  readonly envios: ReadonlyArray<readonly [Direccion, Mensaje]>
  readonly creados: ReadonlyArray<Comportamiento>
  readonly siguiente: Comportamiento
}

type Comportamiento = (mensaje: Mensaje, yo: Direccion) => Efecto

Tres adjetivos de esa firma cargan con todo el peso. Es total: el actor debe poder responder a cualquier mensaje de su protocolo, de modo que ignorar uno es una decisión declarada y no un accidente del control de flujo. Es finita: cada turno produce un número acotado de envíos y de creaciones, lo cual garantiza que un turno termina y hace analizable el sistema turno a turno. Y es pura: no ejecuta efectos, los describe. El runtime es quien los interpreta, y por eso el mismo comportamiento puede correr en un bucle de eventos, en un hilo o en otra máquina sin que su definición cambie una línea.

const contador = (valor: number): Comportamiento => (mensaje) => {
  if (mensaje.tipo === 'incrementar') {
    return { envios: [], creados: [], siguiente: contador(valor + 1) }
  }
  if (mensaje.tipo === 'leer') {
    return {
      envios: [[mensaje.responder, { tipo: 'valor', valor }]],
      creados: [],
      siguiente: contador(valor),
    }
  }
  return { envios: [], creados: [], siguiente: contador(valor) }
}

Fíjate en que valor no vive en ningún campo mutable: vive en el cierre del comportamiento, y cambiar de valor es devolver otro comportamiento. Esa reformulación no es un rodeo estilístico, es la clausura del sistema: si mutar significase asignar, habría que preguntarse quién más puede asignar; si mutar significa designar, la pregunta desaparece por construcción.

La ley de localidad: la dirección es una capacidad

Los tres verbos dicen qué puede hacer un actor. La ley de localidad dice con quién. Durante un turno, un actor solo puede enviar mensajes a direcciones que cumplan una de tres condiciones: venían dentro del mensaje recibido, las creó él mismo en ese turno, o ya las conocía porque estaban en su comportamiento. No existe un directorio global, no se puede adivinar una dirección, no hay aritmética de direcciones. El grafo de comunicación solo crece por transmisión explícita.

type Conocidas = ReadonlySet<Direccion>

function conocidasTrasElTurno(
  previas: Conocidas,
  llegadas: ReadonlyArray<Direccion>,
  creadas: ReadonlyArray<Direccion>,
): Conocidas {
  return new Set([...previas, ...llegadas, ...creadas])
}

De aquí se sigue una lectura incómoda de las comodidades modernas. Un registro global que permita localizar a cualquier actor por un identificador textual —el systemId de XState, el registro de nombres de Erlang, el directorio de granos de Orleans— reintroduce exactamente la autoridad ambiental que la ley de localidad prohíbe: cualquiera que conozca la cadena de texto adquiere la capacidad. Es una traición pragmática y muchas veces correcta, porque el arranque de un sistema real necesita algún punto fijo, pero conviene tratarla como lo que es. Cada nombre global es una puerta que ya no puedes cerrar con un argumento estructural, solo con disciplina.

Entrega garantizada, orden no garantizado

El modelo postula que todo mensaje enviado acaba llegando. Y postula, con igual firmeza, que no hay cota alguna sobre cuánto tarda ni ordenación alguna entre mensajes de emisores distintos. Confundir ambas cláusulas es el error conceptual más caro del área, porque de su combinación sale una propiedad que la mayoría de los modelos de concurrencia no admite: el no determinismo no acotado.

// La entrega esta garantizada, luego el mensaje leer llega SIEMPRE
// y el actor se detiene: el programa termina en todas las ejecuciones.
// Pero el retardo no tiene cota, luego el total devuelto no tiene cota.
const detenido: Comportamiento = () => ({ envios: [], creados: [], siguiente: detenido })

const contando = (n: number): Comportamiento => (mensaje, yo) => {
  if (mensaje.tipo === 'leer') {
    return {
      envios: [[mensaje.responder, { tipo: 'valor', valor: n }]],
      creados: [],
      siguiente: detenido,
    }
  }
  return { envios: [[yo, { tipo: 'incrementar' }]], creados: [], siguiente: contando(n + 1) }
}

Este programa siempre termina y su resultado no está acotado por ninguna función computable de la entrada. La semántica de comandos guardados de Dijkstra, construida sobre precondiciones más débiles, asume no determinismo acotado: si un programa termina siempre, existe una cota sobre sus desenlaces. El actor de arriba refuta esa asunción, y por eso Clinger tuvo que levantar en 1981 una semántica denotacional sobre dominios de potencia para darle sentido. La consecuencia práctica llega intacta hasta tu banco de pruebas: cualquier test que afirme que tras N turnos el sistema ya se estabilizó está asumiendo una cota que el modelo no concede. Los actores se prueban observando quiescencia y no contando turnos.

flowchart LR
R1[llega m1 a A] --> S1[A envia m2 a B]
R1 --> R2[llega m3 a A]
S1 --> R3[llega m2 a B]
R3 --> S2[B envia m4 a C]
R2 --> S3[A envia m5 a C]
S2 --> X[orden de llegada a C indefinido]
S3 --> X
style R1 fill:#89b4fa,color:#11111b
style X fill:#f38ba8,color:#11111b

El actor frente a CSP y al cálculo pi

La familia de modelos de concurrencia por paso de mensajes tiene tres miembros mayores y se distinguen por una decisión temprana: qué entidad recibe nombre.

Nombrar el canal en lugar del proceso parece un detalle de notación y decide el resto del edificio. Si el nombre es del canal, la identidad de quien lee no forma parte del modelo, y entonces no puedes decir reinicia lo que hay detrás de este canal: la supervisión deja de ser expresable y hay que reconstruirla fuera. Si el nombre es del actor, la supervisión es natural pero pierdes la contrapresión gratuita, porque un envío que no espera no puede frenar a nadie. La cita síncrona de CSP regula el flujo por construcción; el modelo de actores tiene que reconquistar esa regulación con buzones acotados, que es precisamente el tema de la lección del buzón.