Affine Ordered Call-by-Push-Value Language
- The paper presents an affine ordered call-by-push-value calculus that unifies linear resource management with explicit destructors and exception handling.
- It enforces strict LIFO resource usage through ordered contexts and explicit move operations, ensuring predictable allocation and deallocation.
- The model bridges formal type theory and practical systems by reflecting principles found in languages such as C++ and Rust for robust resource safety.
An affine ordered call-by-push-value (AOCBPV) language is a typed programming calculus integrating linear resource management, computational effects, exceptions, and explicit destructors for automatic resource cleanup. The paradigm synthesizes features from linear logic, semantic models of effects, and practical system languages (notably C++/Rust), yielding strong resource-safety guarantees while supporting modern programming tasks such as allocation/deallocation, exception handling, and move semantics (Congard et al., 27 Oct 2025).
1. Linearity, Order, and Resource Safety
AOCBPV enforces strict resource management through linear and ordered usage of variables. In the linear fragment, every resource is used exactly once; the ordered fragment strengthens this requirement, enforcing left-to-right or LIFO usage discipline, and precluding implicit exchange or permutation of resources. This discipline ensures that resources are never aliased or used after being freed:
- Linearity: Each binding is consumed once; weakening (erasure) is forbidden except via explicit destructors in the affine variant.
- Order: Contexts are ordered sequences; resource deallocations follow stack-like (LIFO) behavior, mirroring control flow in exception-driven languages.
- Resource safety theorems: Evaluation always returns the freelist (“ambient state”) to its original configuration (in the ordered case), or a permutation thereof (in the linear case), guaranteeing absence of leaks and double-frees.
This approach generalizes the semantics of resource safety from practical languages to abstract type-theoretic setting, yielding strong static guarantees.
2. Type System and Syntax
AOCBPV employs polarized types and stratified expressions to encode both values and computations:
- Positive types:
- Negative types: $N, M ::= A \multimap_2 B\,|\,A \With B$
Special resource types (), tensor (), sum (), and function spaces () distinguish between resourceful entities and control constructs. Expressions and values are further divided by polarity:
- Values: variables, constructed values (pairs, sums), allocation/deallocation primitives ($\New,\Delete$), destructors, etc.
- Expressions: applications, lets, pattern-matching, exception raises/handlers, explicit move/exchange operations.
The typing judgment takes the form , with an ordered or affine sequence.
Example Typing Rules
| Rule | Form | Side-Effect/Resource Impact |
|---|---|---|
| Variable | None | |
| Allocation | $\vdash \New:1\multimap_2(R\oplus 1)$ | Pops/fails from freelist (ordered/linear) |
| Deallocation | $\vdash \Delete:R\multimap_2 1$ | Returns resource to freelist |
| Move | $\Gamma, y:B, x:A, \Gamma' \vdash (x, y)\In t:C$ | May alter destruction order |
| Drop/Destructor | $\vdash \DropB:A\multimap_2 1$ | Runs destructor as side effect |
| Exception | $\vdash \RaiseB:E\multimap_2 A$ | Triggers cleanup by destructors |
The move (exchange) operation is explicit, reflecting the necessity to control resource freed order (random-release vs LIFO). Weakening (drop) is permitted only via explicit effectful operations, invoking destructors.
3. Effects, Exceptions, and Destructors
AOCBPV models effects via monads, in particular the allocation monad , and extends it to handle exceptions:
- Allocation monad: handles resource lists.
- Effect monad for exceptions: generalizes to exceptions , propagating errors and triggering resource release via destructors.
- Strength for : Exists only when the context supports side-effectful weakening (via destructors), modeled in the slice category .
- Destructors: Objects , assigned per positive type, specify cleanup actions to run as resources are erased. Monoidal structure combines destructors for products.
Weakening in AOCBPV can only occur by running the appropriate destructor. Exception propagation entails traversing the stack/context and invoking destructors for all variables in scope, paralleling RAII or unwind-protect mechanisms found in C++/Rust.
4. Operational Semantics
AOCBPV uses a stack-based abstract machine for evaluation:
- Commands: , with the freelist, the term, the stack, the polarity.
- Key reductions:
- Allocation ($\New$): Pops from freelist if available; fails (raises) if not.
- Deallocation ($\Delete$): Pushes resource to freelist.
- Move (exchange): Executes explicit operations, possibly rearranging resource destruction sequence.
- Drop: Evaluates destructor; non-structural weakening.
- Exception raise/handle: On exception, invokes destructors for all variables in the context; restores resource state.
- Resource-safety invariants: At the conclusion of a computation, the freelist is restored to its initial state (ordered) or a permutation thereof (linear). Affine weakening releases resources using the specified destructors.
5. Curry-Howard-Categorical Correspondence
AOCBPV realizes a Curry-Howard-Lambek correspondence in the presence of linearity and effects:
- Type-theoretic: Types and destructors are paired as in the slice category ; weakening and exchange are explicit morphisms with side-effects.
- Categorical: The strength of the monad is guaranteed only when contexts have associated destructors; the tensor product in handles composite resource destruction.
- Exception safety: The interaction of effects, exceptions, and resource erasure is fully captured by the categorical model, with explicit destructors modeling control flow.
Destructors, explicit drop and exchange, and side-effectful operations correspond to morphisms or transformations in the categorical semantics; the overall model systematizes safe resource handling in affine/ordered type systems.
6. Comparative Summary
| Feature | L/OCBPV (linear/ordered) | AOCBPV (affine-ordered, exceptions) |
|---|---|---|
| Resource aliasing | Never | Never |
| Weakening | Not allowed | Allowed, via explicit destructor |
| Exchange/Move | Only in linear fragment | Via explicit operation |
| Effects | Allocation, deallocation | Allocation, exceptions, destructors |
| Exception safety | Explicit in types | Automatic via destructors |
| Resource safety | LIFO/unique usage | Guaranteed via destructors |
7. Significance and Implications
AOCBPV refines fundamental notions of resource management and effectful computation. The explicit identification and invocation of destructor morphisms in the type system provides guaranteed resource safety even in the presence of control-flow altering effects (exceptions), aligning formal semantics with production-grade systems practices. The move and drop operations clarify and make manifest the critical distinctions between structural and effectful resource manipulation, resulting in modular proofs and extensible models.
This calculus provides robust foundations for future design of resource- and effect-sensitive programming languages, as well as formal verification efforts for safety properties, especially in settings where predictable cleanup and exception safety are critical. The categorical models and the Curry-Howard interpretation suggest further generalization to richer fragments (dependent types, graded effects) and modular synthesis across semantic paradigms.