THE DLL PROBLEM

2025-12-03 · updated 2026-05-17

In most languages (C, C++, Rust), you can easily create a Doubly Linked List (DLL).

typedef struct Node {
    int val;
    struct Node* prev;
    struct Node* next;
} Node;

In a DLL, every node has a pointer to its neighbor, and every neighbor has a pointer back.

This is a Cycle.

Cycles are the enemy of deterministic memory management.

1. If you use Reference Counting (Swift/Python), A will never die because B holds a reference to it, and B will never die because A holds a reference to it. They leak memory forever.
2. If you use Arena-Based Memory (CLEAR), child nodes die when the function returns. If you try to point back to a parent, you're pointing to a corpse.

The Solution: IDs and Centralized Lookups

In CLEAR, we forbid shared mutable cycles.

This seems like a huge limitation, until you realize that the vast majority of programs do not need DLLs.

• You need a DLL for: A text editor's buffer, a kernel's task scheduler, or a high-performance LRU cache.
• You do NOT need a DLL for: A web server, a database client, a CLI tool, or a business application.

In CLEAR, you'd have to use a list to manage the pointers, like so.

STRUCT List {
  nodes: Node[]
}

STRUCT Node {
  val: Int64,
  prev_idx: Int64,
  next_idx: Int64
}

• If this IS your product/business, CLEAR will probably hinder you rather than help you.
• CLEAR is designed to make optimization for cache locality as EASY as possible (without having to manage literally all memory like C).
• By using IDs/Indices instead of raw pointers, CLEAR guarantees:
  1. Memory Safety: No dangling pointers.
  2. Concurrency Safety: No race conditions on cyclic structures.
  3. Refactoring Ease: You can move the entire list in memory without breaking pointers.

CLEAR optimizes for the 99% case, where safety and organization are more important than raw pointer soup.

Source: docs/manifesto/DLL-PROBLEM.md