Materialized worlds deserve a frontier language #X7Q90E

This page takes an affirmative position: frontier-shaped computation is a real organizing principle for luvcraft, and Common Lisp gives us unusually good means to make that principle executable. The intention is not merely to extract a queue utility from lighting. It is to grow a small frontier language in which a derived world can state, at its own semantic level:

This is generality as clarification. A light module should be able to read primarily as the law of voxel light: where illumination originates, how a face relation attenuates it, how competing contributions join, and what counts as fixation. Packed buckets, chunk crossings, candidate extent, counters, and publication remain fully real, but become named machinery rather than hundreds of lines interleaved with that law. The same gain is available to fluid motion, fire, components, terminal surfaces, dependency rebuilding, and other materialized worlds without pretending that those domains have the same transfer rule.

The first executable slice now lives beside the established lighting system. luvcraft/frontier.lisp defines inspectable frontier programs, retained execution evidence, packed finite priority buckets, and a compiler-visible voxel-relation traversal. luvcraft/frontier-light.lisp uses that vocabulary for a greenfield, from-scratch monotone light program:

The declaration is an inspectable CLOS definition, while its realization is one closed loop over specialized arrays. On a three-chunk proof world with vertical and lateral seams, occlusion, a sky shaft, and competing emitters, the new program produces exactly the reference oracle's sky and block arrays with the same number of site visits. The compiled program is now the only production solver. The deliberately simple oracle lives in the explicit luvcraft/light-reference system: it can compare a captured candidate without publishing it, but cannot be selected accidentally by runtime dispatch:

#53Q1II states the paradigm explicitly: these are compiled sparse kernels, formed by composing a frontier/control IR with the quantity-checked arithmetic IR and lowering the result to a chosen scalar, SIMD, or GPU execution plan. #PJY6E1 records the first real compiler path: the same voxel-light-addition definition now also carries its local law, and compile-frontier-program closes it over the sky or block field into one scalar loop that agrees exactly with both older solvers and runs faster than either. #T2G95K describes the kernel language, #FE0O5R what a family contributes, #716UN6 how bindings reach storage, and #55IRJO the terminal wall as the second compiled client.

The retired solver remains only as test/reference evidence. Incremental invalidation, removal, and residency reconciliation have since joined the addition fixpoint as compiled frontier programs (#K3WRD3). Misspelled or retired solver names signal rather than silently changing algorithms. This keeps differential evidence available without preserving a second operational truth.

The proof carries cost evidence at the same semantic boundaries. Both solvers emit nested CPU/Tracy zones for the whole solve, sky and block seeding, propagation, and frontier draining. Each retained frontier execution records semantic evidence--visits, relations, admissions, crossings, and peak frontier size--while Tracy owns interactive temporal structure. The CPU trace and the retained A/B result record allocated bytes, garbage-collection time, and the number of automatic collections crossing each dynamic extent. A/B comparison therefore asks four different questions without confusing them: are the fields identical, did the programs perform the same semantic work, where did the physical realizations spend time, and how much memory pressure did they create? The ordinary production worker traverses these same zones, so a live Tracy capture observes the selected solver in the actual asynchronous world path, not only in a special benchmark. #J5KRQ9 explains how these instruments compose.

The first terrain measurement is already useful specialization evidence. On fifteen alternating solves of the same nine-chunk captured world, both programs produced equal fields and made 30,534 site visits. The medians were 22.676 ms and 1.125 MiB allocated for the legacy solver, versus 30.784 ms and 2.560 MiB for the frontier solver: 1.36 times the time and 2.28 times the allocation. A sustained batch of forty equivalent captures made the memory pressure tangible: 51 MiB allocated by the legacy solver and 102 MiB by the frontier solver, with one garbage collection crossing each batch.

That original result is retained here because the ensuing explanation is a small demonstration of the language paying for itself. The fields and visit counts excluded semantic divergence; matching 2,304-site seed frontiers and identical bucket capacities excluded different growth. Phase allocation then isolated the excess to admission, where one runtime-constructed type specifier allocated three conses on every push. #GJZL85 records the fix and the reversal of the allocation result. The remaining time difference now exposes a clean representation question, including the sealed-dispatch possibility in #U84XNW, rather than an indistinct mixture of algorithm and garbage collection.

Mentioned in: 5. Voxel lighting keeps oracle, experiment, and production live

Frontier is an operational pattern, not merely a queue #NXXOQT

The small Haskell repository mbrock/frontier at 1688ab1 asks why breadth-first numbering, A* search, and Cheney copying garbage collection can all become instances of one short program. Its answer is more specific than “they use a worklist.” Each computation combines:

• an unfolder which reveals adjacent work without choosing traversal order;
• a frontier which chooses the next item;
• a memo which gives discovered identities stable results;
• a planning rule which admits, rejects, prioritizes, or coalesces new work; and
• a two-phase materialization rule which reserves a result before adjacent results exist and commits it once those results can be named.

The repository is useful to luvcraft as source evidence, not as a library to port. Its Map, Seq, lists of plans, and monadic interfaces make the relationships unusually legible. Luvcraft's lighting evidence #QS1ERH says that a voxel implementation needs quite different physical machinery: packed parallel vectors, small finite priority buckets, dense fields, and compiler-visible iteration. The source can teach the separation of responsibilities without prescribing the hot-loop representation.

This page first describes what the Haskell program actually does. It then uses that account to classify the frontier-shaped work already present, or plausible, in a Minecraft-like world. Claims about frontier are observations of that repository; the final vocabulary is a proposal for luvcraft.

Mentioned in: The fixed-point algebra should wait for a second client

Five roles make the engine legible #6BM1IQ

The public types in FrontierTraversal.hs divide the computation into five roles. Omitting monadic plumbing, their shape is:

data Step f b a e
  = Done b
  | Kids (f (a, e))

data Node a b = Node
  { nodeSeed   :: a
  , nodeResult :: b
  }

data Plan a b k = Plan
  { planKey    :: k
  , planSeed   :: a
  , planUpdate :: Node a b -> BucketUpdate (Node a b)
  }

data FrontierAlg m f a b k e = FrontierAlg
  { initResult   :: a -> m b
  , commitResult :: Node a b -> f b -> m ()
  , planChildren :: Node a b -> f (a, e) -> m [Plan a b k]
  , priorityOf   :: Node a b -> k
  }

Step lets unfolding either expose a layer of labelled children or stop with a completed result. Node keeps a seed beside the result already reserved for it. Plan is a scheduling instruction rather than a child: it adds a priority and a bucket-update policy. FrontierAlg supplies the four client decisions. Separate MonadMemo and MonadFrontier interfaces supply identity and scheduling storage.

The type variables are not decoration. They prevent a common collapse in which “neighbor,” “unvisited node,” “queued item,” and “computed result” all become one vaguely shaped record.

Reservation precedes adjacency; commitment follows naming #L4WPDP

The essential ordering appears in drainFrontier. Roots are first ensured in the memo and pushed. Each iteration then performs this sequence:

flowchart TD
  R["root seed"] --> I["look up or init result"]
  I --> Q["push frontier item"]
  Q --> P["pop minimum key"]
  P --> U["unfold seed"]
  U -->|"Done b"| D["write final memo result"]
  U -->|"Kids"| C["plan children"]
  C --> S["ensure each child's result; schedule admitted work"]
  S --> M["look up every child result"]
  M --> F["commit parent from reserved child results"]
  D --> P
  F --> P

“Child results are available” has a precise and slightly surprising meaning: they have been initialized and memoized, but their own nodes need not yet have left the frontier. The parent therefore does not wait for a recursive post-order fold. It can commit as soon as stable names for its children exist.

For a seed a, let \mu(a) be its memoized result. The scheduler establishes the implication

When a parent with children a_1,\ldots,a_n commits, every \mu(a_i) exists even though some a_i may remain pending. This is the small invariant that makes shared and cyclic structures ordinary rather than special cases.

Memoization is identity preservation, not just a visited set #AQ5EDF

A visited bit answers whether an identity has been encountered. The MonadMemo relationship answers a stronger question: what stable result has been assigned to this seed? lookupOrInit performs the only reservation and writes it immediately, so every later encounter observes the same result.

That distinction matters on a directed acyclic graph with sharing. If two parents point to one child c, both receive the same \mu(c); traversal does not duplicate the child's materialization. On a cycle, an edge back to an already discovered seed also finds a result which can be named before either object is fully committed.

The memo can still be trivial for algorithms that need only discovery. BFS numbering uses the result as a visit number. A voxel connected-component pass might use a bitfield plus a component identifier. A copying collector uses a forwarding address. The general lesson is that discovery often creates a durable correspondence, not merely a boolean historical fact.

Cheney collection is breadth-first materialization #RLNHEF

The repository's most clarifying example is the Cheney heap. The correspondence is exact:

flowchart LR
  FP["from pointer p"] -->|"initResult"| FWD["forwarding p ↦ q"]
  FWD --> Q["reserved to pointer q"]
  FP -->|"unfold"| OBJ["object containing p₁ … pₙ"]
  OBJ --> ENSURE["ensure forwarding pᵢ ↦ qᵢ"]
  ENSURE --> COPY["commit object at q containing q₁ … qₙ"]

Reservation is the forwarding-pointer operation. Commitment copies the one object layer after every child pointer has a to-space name. Shared children remain shared because lookupOrInit cannot allocate them twice. Garbage never enters the frontier because traversal begins only from roots. A Lens Traversal describes an arbitrary root structure, allowing the final pass to rewrite every root through the forwarding memo.

The property tests in test/Main.hs check structure preservation, compact pointer ranges, garbage removal, and preservation of sharing in generated DAGs. The abstraction is therefore not supported only by suggestive examples; the tests exercise precisely the identity claims that make the example interesting.

BFS and A* differ mainly at admission and order #BNUDE9

BFS numbering gives every new seed the next integer in initResult, commits nothing, assigns the neutral priority (), and enqueues every child. FIFO order within the single priority bucket determines the numbering.

A* leaves the memoized result trivial and keeps best-known path costs g(s) in client state. For an edge s \xrightarrow{w} t, planning computes

and emits a plan only when g'(t) < g(t). Its priority is

When the goal leaves the minimum frontier, the unfolder returns Done and the remaining work short-circuits. Thus the same runner expresses two visibly different algorithms because adjacency, admission, priority, and stopping are separate decisions.

This example also exposes a limit. A* may plan the same state again when its best-known cost improves. The memo says that the state has a stable result; the external g field says that its current approximation changed. “Has an identity” and “has reached its final value” are different predicates.

Bucket updates make duplicate work a policy question #BJCG8G

The concrete priority queue is a map from keys to FIFO sequences, accompanied by a min-priority queue of nonempty keys. BucketUpdate receives the proposed item and the existing sequence at one key, then returns a possibly changed sequence and a boolean saying whether it added work. The supplied policies are only enqueue and skip, but the seam can express replacement, deduplication, beam-width limits, or domain-specific coalescing.

This is more than a queue convenience. It puts the question “does this newly observed relation justify future work?” beside the algorithm that knows the answer. A generic queue cannot infer that a dimmer light arrival is obsolete, that two fluid updates at one site should merge, or that a path with a worse cost should disappear. Conversely, baking one deduplication rule into the frontier would make it wrong for clients that deliberately revisit a site.

The relevant abstraction boundary is therefore admission and coalescing, not merely push and pop.

The repository became clearer by becoming less grand #3Y7EQ1

The Git history is part of the evidence. Early versions explored Elgot algebras, hylomorphisms, and several Cheney-specific recursion-scheme modules. Commit 932631b replaced roughly 1,500 lines of those experiments with about 700 lines centered on FrontierTraversal and Heap. The final commit's own message says “change terminology to be less pretentious,” and the README now leads with a worklist-driven traversal engine.

That evolution did not abandon the underlying structure. It found an operational vocabulary in which the structure could be inspected:

unfold
reserve
plan
schedule
look up
commit

This is a useful precedent for luvcraft. Mathematical interpretations can help discover laws and counterexamples, as #EQ6GLY argues, while the engine still speaks in terms a profiler and debugger can show directly.

Minecraft contains several families of frontier work #SRJEKA

“Flood fill” is too narrow a name for the work a voxel game performs, while “general graph solver” is too broad to guide representation. The useful middle ground is a family of spatial maintenance problems sharing explicit frontiers and materialized state:

Some rows operate over the six face-neighbor relation; others use faces, ports, visibility sets, chunk dependencies, or a metric radius. #E4T0PD is therefore still the right separation: the domain owns primitive stepping, a neighborhood policy chooses relations, and the maintenance rule decides what those relations mean.

Discover, relax, and invalidate are three different dynamics #DURBKN

The workloads fall into at least three algorithmic families.

1. Discover once. Connected components and terminal-wall assembly usually assign each reachable site once for one source revision. A visited bit or component memo prevents repeated work.

1. Relax monotonically. Distances, influence, and light addition keep a best-known value. For a transfer T_e along edge e and join \sqcup, a site changes by

   x_v \leftarrow x_v \sqcup T_e(x_u).

   It enters the frontier only when this update strictly changes x_v. Finite light levels make termination especially plain.

1. Invalidate and rebuild. Removing a source, conductor, support, or resident neighbor can make a previously justified value too large. The system must trace invalid dependencies or conservatively clear a region, then run monotone addition again from surviving evidence. Voxel lighting's removal and addition queues in #SKRELT are the current concrete example.

These families can share storage, adjacency, counters, and scheduling machinery. They should not be forced through one callback protocol that pretends deletion is an ordinary join or that every discovered node is final. The fixed-point shape proposed in #BA9MCA is one client protocol over a more basic frontier substrate, not the definition of that substrate.

Mentioned in: Families own admission, commit, and priority, Invalidation is a family with a companion frontier

Terminal walls supply a second, deliberately simpler client #K3PCP3

A planar rectangle of adjacent terminal-material blocks is a useful discover-once client. Starting from a placed or changed block face, the pass can traverse coplanar face neighbors of the same material, reserve a candidate surface identity, and collect bounds and membership. It then validates that the bounding rectangle is full and publishes one display surface over the participating blocks.

flowchart LR
  E["block edit"] --> S["seed affected terminal faces"]
  S --> W["discover coplanar component"]
  W --> B["accumulate orientation and bounds"]
  B --> V{"every rectangle site present?"}
  V -->|yes| P["publish terminal surface materialization"]
  V -->|no| X["publish components or no display, by chosen rule"]
  P --> G["project terminal grid and Slug draws over the whole face"]

Unlike light, the terminal surface need not revisit a site because a numeric approximation improved. Unlike a permanent world entity, its identity is derived from block material, orientation, adjacency, and source revisions. Breaking one block invalidates the old component and may discover several new ones. That places terminal walls between ordinary component labeling and incremental connectivity.

The terminal grid described by #RD8AEI remains a separate domain. The block frontier discovers where the display surface exists; Ghostty and the terminal presentation determine what cells the display contains. Surface geometry maps between those domains without making one terminal cell equal to one voxel block.

Mentioned in: Adjacent terminal-material blocks define one unified display surface, Terminal walls are the second compiled client, The fixed-point algebra should wait for a second client

Voxel efficiency requires translating the algebra, not its objects #RR9ODK

The Haskell carrier deliberately favors clarity: Map memoization, a Map of Seq priority buckets, allocated lists of Plan values, traversable child layers, and monadic state. Those choices make the experiment easy to vary and test. They are not an acceptable inner-loop cost model for millions of voxel visits.

Luvcraft's existing packed light worklist records the relevant facts. Moving from retained structures and conses to parallel vectors reduced one measured solve from about 264 MB to 31.8 MB consed without changing its 2.43 million visits. Changing scheduling to sixteen brightest-first buckets then reduced the solve to about 13.3 MB, 340,050 visits, and 0.18 seconds. Representation and order were independent performance dimensions.

The luvcraft translation should therefore preserve semantic seams while specializing physical execution:

One dispatch when choosing a maintenance policy may be useful. Generic function calls, closures, conses, and coordinate allocation per edge would put abstraction precisely where #FGT96H says the current profiler is most sensitive. A macro can expose the algebraic phases to source readers while expanding the trusted inner loop over primitive arrays.

Mentioned in: Adjacent terminal-material blocks define one unified display surface

A frontier language composes meaning with specialized execution #QHBZJZ

The unification is real precisely because it is layered. We do not need one generic call per edge, or one object shape for every domain, to possess a shared language. We need stable compositional roles which can be lowered to the right concrete execution:

flowchart TB
  D["chunk domains and checked windows"] --> N["client neighborhood iteration"]
  F["materialized fields and revisions"] --> M["maintenance policy"]
  N --> M
  P["packed frontier storage and priority discipline"] --> M
  M --> C["candidate mutation / result reservation / commit"]
  C --> U["coherent publication"]

The reusable words are concrete and already beginning to exist:

• packed frontier ownership, growth, clearing, counters, and retention rules;
• finite priority-bucket disciplines and perhaps FIFO/LIFO alternatives;
• validated source-site scopes with allocation-free local and crossing neighbor iteration;
• dense visitation, best-known-value, component, and dirty-state materializations; and
• lifecycle rules for candidate state, stale inputs, and coherent publication.

Client programs own transfer laws, admission predicates, removal semantics, stopping conditions, and the interpretation of unavailable neighbors. This is what makes the abstraction powerful: light remains unmistakably light and a terminal wall remains unmistakably a terminal wall, while both can speak in the same precise language about frontier, domain, materialization, extent, and publication.

Mentioned in: Adjacent terminal-material blocks define one unified display surface

Frontier programs are compiled sparse kernels #53Q1II

The proposed frontier language is a DSL compiler, not a generic worklist framework whose inner loop depends on accidental devirtualization. A live, inspectable program definition remains open to Common Lisp development; one compilation closes that definition over particular fields, domains, neighborhoods, representations, and an execution plan, then emits the exact scalar, SIMD, or GPU machinery required by that realization. This is the explicit staging which C++ templates and Haskell type-class specialization obtain through their host languages, but here the generated program and every choice which produced it can themselves be ordinary Lisp objects.

The compiler composes two deliberately different languages:

flowchart TB
  F["frontier program IR<br/><small>family, domain, neighborhood, effects, fixation, publication</small>"]
  A["arithmetic IR<br/><small>quantity-checked transfer, join, admission, priority</small>"]
  C["frontier compiler<br/><small>bind fields and choose a physical plan</small>"]
  S["closed scalar Lisp loop"]
  V["columnar SIMD batches"]
  G["bulk GPU passes"]
  W["GPU work graph"]
  F --> C
  A --> C
  C --> S
  C --> V
  C --> G
  C --> W

The arithmetic language owns pure value laws: derive a propagation loss, compute a candidate, compare it with a destination, join compatible values, and derive a priority. The frontier language owns work-generating effects: seed, expose a relation, read and commit fields, admit another site, settle or invalidate work, and publish a coherent candidate. Chunk lookup, unavailable neighbors, queues, atomics, revision stamps, and publication do not become arithmetic expressions. Conversely, a light attenuation law should not be duplicated as handwritten scalar, SIMD, and shader arithmetic. This sharpens the local-law boundary anticipated by #WEE8P5 and realizes the checked field kernel of #ADR040 through the multi-backend arithmetic medium #5N6SOQ.

One execution plan need not contain a conventional queue. The physical meaning of “unsettled work” may be a packed bucket frontier, a FIFO, an active bitset, current/next append buffers, component parents undergoing pointer jumping, or records emitted between GPU nodes. Two sources make that range concrete:

• Kuth et al.'s 2025 real-time GPU tree generator uses GPU work-graph nodes which consume typed tree records and emit recursive stem, leaf, and mesh work. This is a heterogeneous, dynamically growing frontier realized by the device scheduler.
• Jain et al.'s 2024 FastFlow instead turns terrain flow into regular bulk GPU iterations: rake-compress and pointer jumping accumulate stream trees, while a Borůvka-style process merges depression basins. Its GPU may run a fixed logarithmic number of rounds rather than synchronizing with the CPU to detect early convergence. Here the frontier is evolving dense relations, not an emitted queue.

These are source observations, not a claim that luv already has either GPU backend. Their design consequence is that :frontier-layout alone is too narrow to describe compilation: layout is one part of an execution plan. The compiler may select a different algorithmic realization when the program declares and tests the laws which justify it--for example monotonicity, associative joining, an acyclic recipient relation, finite priority, or a bounded round count. Such laws are semantic claims with differential and property evidence, never optimistic compiler annotations.

The same source can make SIMD explicit without demanding that irregular scheduling itself vectorize. A plan may drain a homogeneous bucket cohort, separate same-materialization interior sites from crossings, borrow raw columns once, evaluate transfer and admission over lanes and masks, compact successful lanes, and handle a scalar tail. Selection occurs outside the hot loop. The scalar lowering remains the reference realization for exact field, visit, and arithmetic conformance.

Quantity meaning survives compilation while quantity wrappers do not. The current :sky-propagation-level and :block-propagation-level fields are already different dimensionless kinds over the same u8 encoding; neither should be renamed radiance or illuminance merely because future lighting will be more physical. A richer kernel may distinguish radiance, irradiance, luminance, spectral or photon quantities, material transmittance, and photopic, scotopic, or mesopic conditions at its checked boundary, then still execute over plain integer or floating lanes. Physicalization therefore strengthens this compiler seam: it does not make a quantity object per voxel.

The current implementation is a useful manually staged compiler prototype:

The large binding list of do-voxel-frontier-relations is thus not the desired human-facing API. It is evidence about the lowered loop. A pleasant kernel source should primarily name fields, relations, transfer, join, admission, priority, and lifecycle; the compiler introduces offsets, crossing flags, buffer access, counters, and temporaries while retaining source provenance for inspection. CLOS remains the open control plane for definitions and backend protocols, while generated code deliberately contains no generic dispatch at the per-site or per-relation grain.

Mentioned in: Materialized worlds deserve a frontier language, The kernel language names fields, constants, predicates, and laws, The shared questions are now concrete, Fast generic functions can specialize a sealed semantic domain, Compile the monotone light kernel to scalar Lisp

The kernel language names fields, constants, predicates, and laws #T2G95K

A frontier program is now written as its own semantic source rather than as a name attached to a handwritten loop. Voxel light reads:

The clauses divide along the two languages of #53Q1II. :fields names roles the program reads or writes at source and target without saying where they live. :constants are values supplied when a realization runs; :predicates are raw truth values about the exposed relation, such as whether its direction is the constant direct-direction or whether it crosses a chunk. :transfer, :admission, and :priority are arithmetic expressions over (FIELD ROLE) reads, predicates, and constants, parsed by the arithmetic frontend and quantity checked against the bound fields, so the one transfer law is checked once as sky propagation levels and once as block propagation levels. as-field-quantity is the explicit boundary at which attenuation steps become propagation-level differences; the checker refuses the subtraction without it. light-propagation-loss is an ordinary define-lisp-arithmetic-function: the seeds call it as a function, while the kernel inlines its checked definition.

A realization exposes three entry points besides the drain: admit seeds a site through the family's law with a supplied value, relate exposes one relation from a virtual source (#581ZQP), and schedule pushes a site whose value stands for reconsideration. Families with a secondary effect take a companion frontier (#ZEENY3).

The realization retains everything the reader could want: the parsed expressions with their quantity specifications, the emitted lambda forms, and the compiled functions. frontier-realization-drain-form prints the whole loop, and the light tests assert that it contains no arithmetic dispatch and no funcall. The reserved words of the language--source, target, materialization, offset, value, window, crossing, direction=--are recognized by name so programs and bindings can be written in their client packages.

Mentioned in: Materialized worlds deserve a frontier language, Compile the monotone light kernel to scalar Lisp

Families own admission, commit, and priority #FE0O5R

The :family clause is semantic, not a label. #DURBKN's dynamics become compiler knowledge:

A definition is checked against its family when it is defined, so a monotone program without a relaxed field fails before any realization. This is why the light program states only its transfer, and the terminal program only its admission: strict improvement, brightest-first scheduling, and visit-once memoization are what those families mean. #ZEENY3 adds the third dynamic of #DURBKN. Further families (A*-style external cost, bounded rounds) add methods on frontier-family-law-forms without touching any client.

Mentioned in: Materialized worlds deserve a frontier language

Bindings close a program over storage #716UN6

compile-frontier-program takes the definition, one frontier-field-binding per role, and a site-domain template. A binding names the represented-value declaration that gives the field its quantity and Lisp type (for light, the :sky-light voxel field definition and the light-opacity slot declaration), the lanes it borrows once per materialization, and read and write templates over those lanes:

The emitted loop binds the raw bucket vectors and counters once, borrows a popped source's lanes and reads its field values once per pop, and at each relation either reuses those lanes (a local step) or borrows the crossing materialization's (an if crossing). Field values are read into declared variables, so the inlined law is fixnum arithmetic over (unsigned-byte 8) reads. A :lazy binding is instead read where the law mentions it, which lets a short-circuiting admission skip an expensive probe. The popped site is validated once and its relations are primitive fixnum steps through do-chunk-site-neighbors (#FGT96H). Nothing per relation is generic, rechecked, or allocated; the only allocation left in a warmed drain is the window's coordinate key at chunk crossings (#L84JCX), and a test bounds it by the crossing count.

The brightest-first layout takes its bucket count from the relaxed field's legal values, so the frontier's priority meaning is the field definition itself. Realizations are cached per bound field and invalidated by the definition's revision, so redefining the program in a running image recompiles on next use.

Mentioned in: Materialized worlds deserve a frontier language, Compile the monotone light kernel to scalar Lisp, Pay checked adjacency cost once per visited site

Terminal walls are the second compiled client #55IRJO

#K3PCP3 asked for terminal discovery as a deliberately simpler client. It now is one program:

Its window is the block world itself, whose chunks are the materializations and whose locate-chunk-window-site continues a step across a seam. The memo is a per-chunk bit vector owned by one discovery's table; terminal is an eq against the constant material through the chunk's content column; exposed is a lazy probe of the outward neighbour. Because the program retains admissions, the execution hands back the component as one packed buffer of chunk and offset, and find-terminal-surface folds that into projections and a rectangle test. The old hash-of-coordinate-lists walk is gone; the earlier expectations (rectangle, L-shape, covered, wrong material) and a seam-straddling rectangle whose retained component is exactly its eighteen blocks are the tests.

Mentioned in: Materialized worlds deserve a frontier language

Invalidation is a family with a companion frontier #ZEENY3

Removing a source, or a departed neighbour, leaves levels no surviving source justifies. #DURBKN argued that this is a different dynamic from addition, not an option on it; it is now the :invalidation family, and voxel light's removal program reads:

Three things distinguish the family. First, the source's value is not a field read: a cleared site's field is already zero, so (level source) is the priority it was admitted at--the level it had. Second, the family has a secondary effect: a lit target that the source did not feed is a surviving source, and the drain hands it to a companion frontier--here the addition program's--at its own level, counted as an emission. Third, the retained admissions are the cleared set, which the client walks afterwards to re-admit emitters and relate open sky (#581ZQP) before draining addition.

The compiled reconciler in frontier-light.lisp composes exactly the legacy sequence from these words: invalidate dirty cells and departed neighbours' faces (admit with the old level), drain removal with addition as companion, reseed emitters and open sky over the cleared set, seed arrivals (relate for sky, admit for emitters, schedule for resident neighbours' facing sites, whose values already stand but whose relations must be exposed again), then drain addition. reconcile-lighting selects it through *voxel-light-solver* :compiled.

Evidence is differential and exact: the incremental, random-edit, departure, re-arrival, same-key replacement, and cross-chunk crystal tests run under both reconcilers against the from-scratch reference; a roofing test checks that sky removal clears exactly the sixteen cells of the beam and emits survivors. Over forty ten-edit bursts on six chunks both reconcilers visited 121,110 cells; the compiled one settled a burst in a median 0.55 ms against the legacy 1.25 ms.

Mentioned in: The kernel language names fields, constants, predicates, and laws, Families own admission, commit, and priority, Give frontier light its own invalidation program

The shared questions are now concrete #7U572V

The frontier repository and luvcraft's two clients replace the vague question “should we generalize the flood fill?” with questions that can be answered in code and measurements:

• Can one packed frontier storage vocabulary serve both light levels and terminal component sites without weakening either representation?
• Which admission choices can be selected outside the loop, and which must be macro-expanded into it?
• Is a dense per-materialization bitset sufficient for terminal discovery, or does incremental splitting soon justify retained component metadata?
• Can one validated-site neighborhood scope remove repeated bounds checks for lighting while remaining useful to component discovery?
• Which clients need result reservation in the strong Cheney sense, rather than only visited or best-known state?
• Can every candidate prove its source materialization and boundary revisions before publication?
• Do queue counters distinguish useful visits, stale pops, strict improvements, invalidations, and cross-chunk steps well enough to compare scheduling policies?

The exciting criterion is semantic compression with mechanical strength: clients share storage and iteration laws, retain their own meanings, allocate no per-edge garbage, and become easier to read and observe than their separate predecessors. If several modules can become short declarations of their world laws while the generated or macro-expanded loops remain excellent, that is not abstraction for its own sake. It is the engine discovering one of its native languages. #53Q1II now names the compiler architecture which makes that criterion explicit rather than leaving specialization to macro convention or implementation luck.

Tracy aligns temporal structure with semantic work #J5KRQ9

with-cpu-trace-zone is one instrumentation vocabulary with two independent observers. Its outer observer is a real Tracy zone. When Tracy is stopped, the path is one special-variable test. When Tracy is running, a literal zone uses an interned foreign source location and one begin/end FFI pair. The inner observer is luv's bounded cpu-trace tree, enabled only around an explicit retained capture. It samples host time, allocated bytes, and GC clocks at zone boundaries. The frontier code does not maintain a third per-execution stopwatch: retained executions keep semantic counters, while Tracy and the explicit A/B observation own time.

This division follows the instruments' actual powers:

The drain zones now attach their visit count through Tracy's zone-value API. The A/B comparator emits reference/candidate allocated-byte, GC-millisecond, and collection-count plots. A thirty-pair capture therefore showed every sky drain beside the value 30,534, and the steady allocation samples for both solvers converged to 1,179,696 bytes after #GJZL85. A separate sixty-pair capture measured mean sky propagation at 23.03 ms legacy and 27.63 ms frontier. Tracy thus says both when and how much semantic work; the allocation plot rules out GC as the steady explanation for the remaining time gap.

Tracy also has a C memory-allocation API, but using it honestly would require allocator-level object addresses and matching frees. SBCL owns a moving generational heap, so emitting a fake Tracy allocation for each sampled byte delta would manufacture object identities and lifetimes that do not exist. For Lisp heap attribution, zone-level byte deltas plus SB-SPROF and compiler inspection are the sounder composition.

Mentioned in: Materialized worlds deserve a frontier language

Fast generic functions can specialize a sealed semantic domain #U84XNW

Marco Heisig's fast-generic-functions turns a CLOS generic function into a compiler-specializable one. A client defines the generic function with fast-generic-function as its metaclass, seals a chosen argument domain after installing methods, and supplies enough static argument type information at call sites. On SBCL, the library installs IR1 transforms. The default optimized call bypasses the discriminating function and calls a compiled effective method directly; when every applicable method declares the inlineable method property, it can inline the complete effective method.

This is a beautiful fit for closed physical realization beneath an open semantic boundary, but sealing has exact consequences. No method may later change behavior inside the sealed domain. User-defined standard classes must participate through a sealable metaclass and externalizable prototype instances. The project itself recommends putting definitions, methods, and sealing in separate load stages and measuring with sealing disabled as an A/B control.

The current light result makes its relevance precise:

• The retired execute-frontier-program selector cost only two dispatches per solve; deleting it closed runtime policy but could not explain several milliseconds.
• bucket-frontier-push and bucket-frontier-pop are ordinary functions, but their CLOS slot readers and writers are generic functions in the per-site path. Disassembly of push contains nine accessor FDEFN calls and is 1,044 bytes, versus 644 bytes for the struct-backed legacy push.
• A queue-only run of 1.8 million warmed push/pop operations took 80.14 ms through bucket-frontier and 18.15 ms through the legacy structure. Both perform the same finite-bucket discipline; the generic frontier now allocates zero bytes in that loop.

There are therefore two excellent proof candidates. One makes the frontier accessors fast generic functions and seals the bucket-frontier domain. The other binds the CLOS owner's raw buckets and counters once, runs a compiler-visible drain over local primitive state, and writes the counters back at the boundary. The former tests whether sealed CLOS can itself be the zero-overhead physical language; the latter preserves unrestricted live CLOS at the boundary. Comparing their generated code, live redefinition behavior, and whole-solver Tracy capture remains informative. The compiler proposal #53Q1II gives the second candidate a larger meaning: raw binding is not an adapter around CLOS but one deliberate lowering of an open semantic program. Fast generic functions remain a valuable A/B realization, not a prerequisite for zero-overhead frontier semantics.

Mentioned in: Materialized worlds deserve a frontier language