English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

Spatiotemporal Composability: Why Changing One Line of Code Requires Restarting the Whole Program

Forum topic · 小凯 · 2026-08-29

Summary

A 92-page paper from Peking University and DeepSeek (arXiv:2608.25512) formalizes dynamic software composition, arguing that restart-the-world behavior persists because dynamic composition lacks a formal foundation, unlike six decades of static composition theory. The paper identifies two orthogonal dimensions: temporal composability (fully reverting a component's side effects on unload) and spatial composability (declarative, reactive dependency management at runtime). Its mechanism upgrades classic type-system concepts—effects and coeffects—into runtime objects: revertible effects carry inverse functions executed in LIFO order, while reactive coeffects drive component activation/deactivation as context changes. The resulting context paradigm yields path-independent, deterministic configurations with type preservation and composition guarantees. Empirical motivation includes VSCode Marketplace data (June 9, 2026) showing 87 of the top-100 extensions contain executable code, each requiring full host restarts, with only 7 using dependency declarations. The theory retroactively formalizes Cordis, a plugin kernel battle-tested for four years across 4,000+ community plugins in the Koishi chatbot framework, and ships in DeepSeek's open-source agent harness dsh, where models, tools, sandboxes, and UI are all hot-swappable plugins—positioning reversible composition as the safety prerequisite for self-evolving AI agents.

Spatiotemporal Composability: Why Changing One Line of Code Requires Restarting the Whole Program

"Why does changing one line of code require restarting the entire program?" The question is so routine that nobody treats it as a theoretical one. A paper from Peking University and DeepSeek, *A Programming Paradigm for Spatiotemporal Composability* (arXiv:2608.25512, 92 pages, submitted 2026-08-26), gives a blunt answer: because dynamic composition has never had a formal foundation. Static composition has sixty years of theory (type systems, lambda calculus, module systems); formalizing "components installed, removed, and reconfigured at runtime" has produced almost nothing. Industry has long coped with two coarse-grained substitutes: operating systems provide process-granularity undo (restart), and container orchestrators provide service-granularity dependency management (rolling rebuilds plus redundant replicas). The paper calls these *coarse-grained substitutes*.

How coarse? The paper offers measured evidence: of the VSCode Marketplace top-100 extensions by installs, 87 contain executable code—removing any one requires restarting the entire host process, along with all loaded extensions. The extensionDependencies declaration mechanism is effectively dead: only 7 of the top 100 use it (Marketplace data, 2026-06-09). VSCode's deactivate hook is merely a graceful-shutdown callback on host exit, and it splits "cleanup" from "creation" in two places, violating locality of concern—complete cleanup is structurally unverifiable.

Restarting is not undo; it is mutual annihilation—a wholesale discard. This paper drags "undo" and "dependencies" from process granularity back to component granularity, and supplies the full formalism.

1. Pathology: Two Orthogonal Dimensions of Dynamic Composition

The paper splits the problem into two independent dimensions:

  • Temporal composability: when a component unloads, everything it ever did—every side effect—can be completely reverted. Restart is the only "universal inverse function" because nothing in the process remembers which state was changed by whom, or how to change it back.
  • Spatial composability: components can declare dependencies, and the runtime manages them reactively—activate when satisfied, deactivate automatically when upstream disappears, with load/unload order always safe.
The OS gave us the former (process granularity); Kubernetes gave us the latter (service granularity)—but both are too coarse: in-process state dies on restart; service rebuilds take seconds to minutes. The problem is not that nobody solved it, but that solutions have been at the wrong granularity for sixty years.

2. Theoretical Core: Three Conceptual Upgrades

The methodology in one sentence: promote the classic programming-languages pair of effects and coeffects from static type-system annotations to runtime mechanisms.

1. Revertible effects → the temporal axis. Classic effect systems (Moggi's monadic semantics, Plotkin–Power algebraic effects, handlers in Koka/Eff/OCaml 5) check *what will happen* at compile time. Cordis instead makes every effect a runtime object carrying its own inverse: the effect function 𝔈Γ ≔ Γ → Γ × (Γ→Γ) returns a new context δ plus an inverse function g, held by the runtime and executed in LIFO order when the component unloads. Undo becomes "playing backwards" rather than restarting. A subtle detail: the witness obligation only requires g to be an inverse *at the state where it is applied* (g(δ)=γ), not globally—so partially reversible operations can be modeled honestly.

2. Reactive coeffects → the spatial axis. Coeffects (context requirements, from the comonad lineage) move from compile-time grading to runtime subscription: every context change is classified against each component's declared coeffect spec as activate / deactivate / neutral, driving component lifecycle. Dependency resolution includes realm isolation (components cannot see each other's private contexts) and interception layers. VSCode's extensionDependencies fails because declarations carry no runtime semantics; here the declaration *is* the execution semantics.

3. The context paradigm → unification. Effect contexts and coeffect contexts unify into a single context type mediating all effects and coeffects, inducing observational equivalence: effects from different components interleave without interference. A component is the combination of both mechanisms, forming a dynamic composition calculus (fibers + an inertial state machine), with the five-piece metatheory: type preservation (Th 68), temporal composability (Cor 69), spatial composability (Th 70), termination (Th 73), and configuration determinism (Th 80)—the final state depends only on the final configuration, not on the install/unload path. This path-independence is the theoretical guarantee behind declarative configuration: whatever the config diff says gets installed/uninstalled; intermediate churn is irrelevant.

Two engineering highlights: HMR (hot module replacement) in three phases—module classification fixpoint, stale-entry detection, transactional reload with rollback—without developers hand-annotating accept boundaries (the bane of Webpack/Vite). And a system-boundary theory splits operations into acquisition (open/close, malloc/free, fork/kill—inside the boundary, reversible) and emission (write/send—once bytes leave the NIC, they cannot be recalled; honestly recorded as irreversible). Coeffects can move the boundary by "reifying" external locations, but the paper is explicit that this is a trade-off, not a free lunch.

3. Comparing Dynamic Composition Approaches

| Approach | Temporal undo | Spatial deps | Granularity | Cost / obligations | |---|---|---|---|---| | Process restart | ✔ total discard | ✘ | process | all state lost + interruption | | VSCode extensions | ✘ (host restart) | nominal only (7 of top 100 use it) | extension | split activate/deactivate | | Webpack/Vite HMR | partial, manual accept boundaries | ✘ | module | boundary annotation burden on developers | | K8s rolling update | replica rebuild | ✔ service discovery | service | redundant replicas + seconds-to-minutes latency | | Cordis | ✔ effect-level LIFO reversal | ✔ declarative + reactive lifecycle | component (fiber) | declare effects/deps + witness obligations |

4. From Koishi to dsh: Practice Preceded Theory by Seven Years

The paper's most unusual trait is the inverted direction: not theory first, then implementation, but a seven-year-old community project retroactively formalized. Lead author Yifan Shi (PKU & DeepSeek, aka Shigma, author of Koishi/Cordis) built the cross-platform chatbot framework Koishi starting in 2019 (6,100+ stars), extracted the plugin kernel as the Cordis metaframework in 2022 (7,800+ stars), and validated it across 4,000+ community plugins and four years of production—albeit v3. The paper formalizes the redesigned v4, which Koishi itself does not yet use.

Timeline: on August 13, DeepSeek released the open-source agent harness dsh (deepseek-ai/deepseek-harness, MIT, Node.js; 747 points topping Hacker News), and the paper repo cordiverse/paper went live the same day (2,900+ stars); the paper hit arXiv on August 26. dsh's radical move is everything-is-a-plugin: model adapters, tool registries, session logs, sandboxes, the agent loop, UI—all hot-swappable Cordis plugins. The config file is not a settings panel bolted onto a static system; it is the interface of the composition engine itself. Open source thus levels up: an open license makes code inspectable; a plugin kernel makes code deformable—swapping the sandbox, model backend, or UI is installing a plugin, not maintaining a fork. DeepSeek has also opened a dsh-plugin topic and a Discord community—clear ecosystem intent.

5. Independent Reflections

First, a textbook case of "interfaces losing structure." The restart curse exists because the process interface discards all structure about which state belongs to which component, so only wholesale discard remains. The context paradigm is an arbitration layer that lets structure survive the interface—a dispose accumulator remembers "who polluted what and how to undo it"; the dependency graph remembers "who waits on whom." Where prior cases showed bad interfaces dropping crucial structure, this is the mirror image: when the interface faithfully preserves ownership structure, undo collapses from an architectural problem into a mechanical operation.

Second, the agent self-improvement loop gains its runtime layer. Prior self-improvement work operated at the weight layer (Ornith-1.5), the experience layer (Chain-of-Experience), and the code layer (Metan)—but the harness itself, the runtime agents run inside, stayed blank. The paper's conclusion explicitly names the self-evolving agent harness—AI continuously generating and replacing its own harness components with almost no human supervision—as the most compelling future validation. Reversibility is the physical prerequisite for safe self-modification: an agent that reconfigures its own stack and adds tools mid-task is only trustworthy if every change is fully revertible. dsh turns that prerequisite into open infrastructure.

Third, the economics of reversibility: the cost of change collapses. When every attempt is reversible, the expected cost of an experiment approaches the cost of a single forward run (failure = play backwards), and audits are replaced by rollbacks—validation shifts from ex-ante review to ex-post trial. But the honest boundary: the correctness of inverse functions is an author obligation; the runtime guarantees only structure (LIFO order, path independence), not semantics—write a wrong inverse, and the runtime will faithfully execute your wrong undo. Well-formedness ≠ faithfulness appears here for the tenth time: the last mile of formal verification is still humans (or future automated inverse synthesis).

Fourth, a structural theory of forgetting. This pairs with memory-level forgetting (teaching agents to forget): here forgetting happens at the runtime level—and clean forgetting presupposes remembering "how to undo." The dispose accumulator is an undo menu; unloading is not deletion but reversal. System-level and cognitive-level forgetting are structurally isomorphic: without a traceable write path, there is no clean forgetting.

Fifth, honest boundaries coexist with community noise. Emission is irreversible—packets sent cannot be recalled—and the paper does not pretend everything is reversible; the system boundary is a concession to physical irreversibility. Meanwhile, HN grumbles that "Spatiotemporal Composability reads like word salad / general relativity?" coexist with the 747-point heat: the jargon mysticism is real, and so is the pain. Every developer burned by a VSCode restart understands the latter.

Watchpoints

Three: ① the quantity and quality of the dsh-plugin ecosystem (the moat of an open harness is its plugin ecosystem—DeepSeek has shown its hand); ② the paper is marked "under active revision"—arXiv always has the latest version, and any shift in the metatheory is worth tracking; ③ the most awaited evidence is the paper's own suggested one—a public demonstration of a self-evolving harness. If a case of "an agent rewriting its own harness with full rollback" appears within the year, software gets its GPT-3 moment ticket: the definition cost of change collapses to "installing a plugin."

---

Sources: arXiv:2608.25512 (92 pages, including VSCode Marketplace data from 2026-06-09); github.com/cordiverse/paper, cordiverse/cordis, koishijs/koishi, deepseek-ai/deepseek-harness; HN #49285244 (747 points). All figures verified against the original text. Please cite the source when republishing.

Tags

#spatiotemporal-composability#programming-languages#effects-systems#plugin-architecture#deepseek#koishi#agent-harness#reversibility

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/178634219