La gestión de memoria en lenguajes de programación de sistemas ha sido tradicionalmente un compromiso entre la flexibilidad del conteo de referencias (RC) y la seguridad y rendimiento del borrow checking. Lenguajes como Rust y Swift han intentado combinar ambos, pero a menudo introducen complejidades como RefCell o verificaciones de exclusividad en tiempo de ejecución que pueden llevar a panics. El problema fundamental de la computación que Ante aborda es cómo permitir la mutabilidad compartida con RC y borrow checking simultáneamente, sin sacrificar la seguridad de memoria ni introducir sobrecarga en tiempo de ejecución. Esto es crucial para escenarios donde se requiere flexibilidad (como prototipos de juegos) y luego optimización, o donde la mutabilidad interna es deseable sin los riesgos asociados.

Históricamente, la seguridad de memoria se ha logrado a través de recolección de basura (GC), conteo de referencias o sistemas de tipos con borrow checking. Cada uno tiene sus ventajas y desventajas en términos de rendimiento, predictibilidad y ergonomía. Ante busca una síntesis que combine la ergonomía de RC con las garantías de seguridad de borrow checking, superando las limitaciones de enfoques previos que obligaban a elegir entre uno u otro, o a aceptar compromisos significativos en la experiencia del desarrollador.

Arquitectura del Sistema

Ante implementa un sistema de tipos que permite la coexistencia de tipos de propiedad única (gestionados por borrow checking) y tipos compartidos (gestionados por conteo de referencias). La clave de su diseño reside en el concepto de 'shape-stability', donde una referencia a un objeto de forma estable siempre es válida, independientemente de las mutaciones externas. Esto permite que Ante acepte múltiples referencias mutables a la misma estructura o a sus campos simultáneamente, algo que Rust y Swift no permiten sin mecanismos adicionales como RefCell.

Para la mutabilidad compartida con conteo de referencias (Rc), Ante introduce la conversión uniq. Un uniq es una referencia mutable exclusiva temporal. Cuando se obtiene una referencia uniq a un campo de un tipo Rc (ej. match uniq ship.engine), el compilador de Ante garantiza que, dentro del alcance de esa referencia uniq, ninguna otra variable que pueda contener indirectamente una referencia al mismo objeto Rc sea accesible. Esto previene aliasing inseguro y permite la mutación directa de campos de tipos Rc sin bloqueos o verificaciones de exclusividad en tiempo de ejecución. Para tipos union, la regla es más estricta: si se tiene una referencia mut a una union, no se puede obtener una referencia mut a uno de sus variantes, a menos que se use la conversión uniq que impone las restricciones de alcance mencionadas. Esta aproximación evita los problemas de seguridad de memoria asociados con las union en lenguajes de bajo nivel, manteniendo sus beneficios de rendimiento (datos inline, menos 'pointer chasing').

Flujo de Mutación Segura con `uniq` en Ante

  1. 1 Declaración `Rc` Se declara una variable `ship` de tipo `Rc Spaceship`.
  2. 2 Inicio Alcance `uniq` Se inicia un bloque `match uniq ship.engine`, creando una referencia `uniq` t...
  3. 3 Restricción de Acceso El compilador prohíbe el acceso a cualquier otra variable que pueda contener ...
  4. 4 Mutación Segura Se muta el campo `str` de `StringTheoryEngine` de forma segura.
  5. 5 Fin Alcance `uniq` La referencia `uniq` expira, y se restablece el acceso a otras variables.

Trade-offs

Ganancias
  • ▲ Seguridad de memoria con mutabilidad compartida
  • ▲ Eliminación de panics en tiempo de ejecución por aliasing
  • ▲ Ergonomía de desarrollo para RC
  • ▲ Rendimiento de `union` sin inseguridad
Costes
  • △ Complejidad del análisis de tipos en el compilador
  • △ Posibles cambios de API al añadir campos a structs
  • △ Restricciones de alcance durante conversiones `uniq` 
type Engine =
  | StringTheoryEngine (str: String)
  | ImpulseEngine (fuel: I32)
type Spaceship =
  engine: Engine
  name: String
launch (var ship: Rc Spaceship) =
  // Start scope where nobody can access any other var that might contain a Spaceship
  match uniq ship.engine
  | StringTheoryEngine str ->
    str.[0] := 'z'
  | ImpulseEngine fuel ->
    ()
  // End scope where nobody can access any other var that might contain a Spaceship
Demuestra cómo Ante permite la mutación segura de un campo de un tipo `Rc` (referencia contada) utilizando la conversión `uniq` en un bloque `match`, mientras el compilador garantiza la seguridad de memoria.
type Engine =
  fuel: I32
type Spaceship =
  engine: Engine
  name: String
refuel (ship: mut Spaceship) =
  engine_alias: mut Engine = ship.engine
  // Can still use original `ship`
  ship.engine.fuel := 200
  engine_alias.fuel := 100
Muestra cómo Ante permite múltiples referencias mutables a la misma estructura o a sus campos simultáneamente, algo que es seguro debido al concepto de 'shape-stability'.

Fundamentos Teóricos

El problema de la mutabilidad compartida y la seguridad de memoria ha sido un tema central en la investigación de lenguajes de programación. El concepto de borrow checking fue popularizado por Rust, inspirándose en trabajos como el de Cyclone (Jim Smith, Greg Morrisett, 2002) sobre seguridad de punteros y regiones de memoria. La dificultad de combinar RC con borrow checking sin sobrecarga en tiempo de ejecución se relaciona con el teorema de aliasing-mutability, que establece que no se pueden tener múltiples referencias mutables o una referencia mutable y múltiples inmutables a la misma ubicación de memoria al mismo tiempo de forma segura sin un mecanismo de coordinación. La solución de Ante, con su 'shape-stability' y conversiones uniq con restricciones de alcance, puede verse como una forma de relajar esta restricción bajo ciertas condiciones verificables en tiempo de compilación. Esto se alinea con la investigación en sistemas de tipos más expresivos que buscan garantizar propiedades de memoria y concurrencia sin la necesidad de recolección de basura o bloqueos explícitos, como los trabajos sobre 'region-based memory management' o 'linear types'.