A plugin registers commands, subscribes to events, allocates resources, and changes shared state. Loading is easy because the host can start executing its code. Removal is harder: what happens to every command, listener, allocation, and mutation the plugin introduced? If the host simply stops calling the plugin's entry point, those external changes can remain behind. An event listener may still fire; a resource may still be held; a command may still be registered.
The paper frames the desired property as temporal composability. When a component is removed, its environmental modifications should be completely and safely reversed. That means the runtime needs information about the changes made during execution and, importantly, information describing how to undo them. Cleanup becomes part of the composition model itself rather than an informal convention between a plugin author and a host.
A whole-process restart can erase process-local state, so it can approximate cleanup. But it solves a component-level problem with a process-level operation. Restarting also discards state belonging to unrelated components: caches, connections, partial computation, and other live resources.
For a continuously evolving system, repeated restarts impose downtime or require redundant replicas. The paper therefore identifies a granularity mismatch: software wants component-level dynamic composition, while conventional recovery mechanisms often operate at process or container boundaries. The desired operation is closer to removing one object from a live graph than rebuilding the graph from scratch. A restart may be acceptable for coarse recovery, but it does not provide the fine-grained lifecycle semantics required by dynamically composed components. The distinction becomes especially important when the rest of the running system contains valuable state that should survive the change.
Consider an agent harness that adds or removes tools, memory modules, permissions, or execution components while serving requests. A change should be reversible without taking unrelated components offline. At the same time, a component may depend on another component that can appear or disappear.
That creates two runtime problems: recovering changes made by a component, and reacting when the environment it depends on changes. The paper uses this kind of self-evolving system to motivate a programming model where dynamic composition is explicit. The point is not that every agent must use the same architecture; the example exposes why a runtime that evolves while executing needs stronger composition primitives than ordinary startup-time dependency injection. Both the component's own footprint and its relationships with other components can change, so lifecycle and dependency management have to be treated together.
These problems live on different axes. Temporal composability concerns time: after a component leaves, its environmental modifications must be safely reversible. Spatial composability concerns system structure: components specify dependencies, and their lifecycle responds when those dependencies change.
In plain terms, temporal composability asks, “Can this component leave cleanly?” Spatial composability asks, “Can this component coexist with, find, and react to what it needs?” A useful runtime needs both. A component might have perfect cleanup while having no principled way to discover a newly available dependency. Conversely, dependency resolution alone does not help if removing a component leaves its resources and state behind. The two dimensions therefore describe separate failure modes that must meet in one composition model. This separation also tells us which mechanisms to look for: recovery for time, and dependency-driven lifecycle for space.
Programming-language theory already gives names to these directions. An effect describes how a computation changes its environment. A coeffect describes what a computation requires from its environment. Classical effect systems annotate computations with side-effect information, while coeffect systems enrich the context with environmental requirements.
The paper takes these ideas into runtime composition. Dynamic components need environmental changes and requirements to remain meaningful while the system evolves, so the concepts cannot remain purely static annotations. Effects give us a vocabulary for changes a component causes. Coeffects give us a vocabulary for conditions a component needs. The construction that follows turns those descriptions into operations the runtime can mediate, making the language-level distinction useful for a live component system rather than only for static analysis.
To reason about side effects, make the hidden environment explicit. An effectful computation can be viewed as , but conceptually we expose its context as Here is the shared context, is the ordinary input, and is the ordinary output. For fixed input , the environmental part is , a transformation from one context state to another.
This representation changes what the runtime can see. Instead of treating an event registration or resource allocation as an invisible side effect, the environmental portion becomes a transformation of . That transformation can then be composed and paired with information describing recovery. The ordinary return value remains separate from the environmental change. The simplification is deliberate: we are isolating the part of execution that affects the shared environment so the later recovery machinery has something precise to track.
A forward transformation tells us what changed, but temporal composability also needs a route back. Represent an effect with a pair : moves the context forward and undoes that move. When two effects are composed, their recovery functions compose in the opposite order:
If happened first and second, recovery must undo before . The reversal therefore follows directly from the ordering of state changes. Combining effects automatically combines their recovery operations in the order required for reversal. This turns cleanup into an algebraic operation: composing two changes also tells the runtime how their combined change can later be reversed, provided the individual recovery functions satisfy the required local conditions. The pair is therefore a compact description of both execution and eventual rollback.
The runtime can store the current context together with an accumulated recovery function: A state contains current context and recovery function . Tracking updates both: Recovery applies the accumulated function and resets it:
The first component records where the system is now; the second records how to get back. Each tracked effect extends the recovery function. Recovery consumes that accumulated information and restores the identity recovery function. This is the small runtime state needed for the temporal argument. The notation is abstract, but its operational meaning is simply current context plus a composable record of how prior environmental changes can be undone. The construction is intentionally presented as a runtime discipline: each operation has a precise place in the evolving context, so later composition can reason about it rather than relying on informal lifecycle conventions.
Suppose a plugin registers an event listener, allocates a resource, and inserts an entry into shared context. Each operation can be represented by a forward change plus an inverse: remove the listener, release the resource, and remove the entry. Those inverses accumulate as the plugin runs.
On unload, they execute in reverse order. The local condition is important: each inverse must correctly revert the state at which its effect was applied. If a later operation depends on state created earlier, reverse ordering preserves that dependency. The example is deliberately simple; its purpose is to make the recovery accumulator concrete before the paper strengthens the effect representation. It also shows why generic cleanup is insufficient: the runtime needs recovery information attached to the actual effects that occurred. The construction is intentionally presented as a runtime discipline: each operation has a precise place in the evolving context, so later composition can reason about it rather than relying on informal lifecycle conventions.
The simple model assumes an inverse can be chosen independently of current state. The paper strengthens it so the effect itself receives the current context and returns both the new context and an inverse tailored to that transition: If , the inverse must satisfy
The equation says exactly what recovery means: apply the returned to the state produced by the effect and recover the state that existed before it. The paper also introduces a witnessed form, , to capture this recovery obligation. The inverse is therefore tied to the actual runtime transition. This matters when the information needed for cleanup depends on the state observed during execution rather than on a fixed, globally chosen function. The construction is intentionally presented as a runtime discipline: each operation has a precise place in the evolving context, so later composition can reason about it rather than relying on informal lifecycle conventions.
Effects describe what a component does to its environment. Coeffects describe what the component needs from it. A component can declare a coeffect specification describing conditions required for activation.
When the shared context changes, the runtime evaluates that change against the specification. A change can be activating, because a required dependency became available; deactivating, because a requirement is no longer satisfied; or neutral, because it does not affect the requirement. Lifecycle can therefore follow context changes reactively. The component does not need a separate hand-written rule for every possible dependency transition; its specification supplies the condition while the runtime classifies the change. This gives spatial composability a concrete operational mechanism rather than leaving dependency behavior to convention. The construction is intentionally presented as a runtime discipline: each operation has a precise place in the evolving context, so later composition can reason about it rather than relying on informal lifecycle conventions.
The paper unifies these mechanisms through a shared runtime context. On the effect side, components transform the context and produce recovery information. On the coeffect side, component requirements are evaluated against changes in that same context.
This gives one mediation point for environmental interaction. The paper further introduces observational equivalence so behavior can be compared without depending on irrelevant details of the mediated representation. Components have two relationships with their environment: they change it, and they depend on it. The unified context gives both relationships a common operational setting, which is necessary before properties of multiple interacting components can be stated cleanly. Rather than maintaining separate worlds for effects and requirements, the paradigm makes them interact through one evolving context. The construction is intentionally presented as a runtime discipline: each operation has a precise place in the evolving context, so later composition can reason about it rather than relying on informal lifecycle conventions.
Once many components share a context, local reversibility is not enough. One component's effects must not unexpectedly interfere with another's tracked effects. The paper captures this through effect independence.
On the dependency side, context changes from different components need to compose consistently; coeffect commutativity expresses the relevant consistency when compatible changes are interleaved. Together these properties support reasoning about components that activate, deactivate, and interleave without their bookkeeping becoming an uncontrolled source of interference. The purpose is compositional reasoning: local effect and dependency properties should remain meaningful when several components participate in the same evolving runtime. This is the step from a reversible single plugin to a system of mutually present components. The important qualification is that these claims belong to the formal model and its stated assumptions; the article should not generalize them to every existing plugin architecture.
The calculus packages the runtime machinery into components and fibers. A component is the compositional unit, while a runtime fiber represents its evolving contextual state.
Three operational concerns organize dynamic composition: orchestration coordinates components, lifecycle governs activation and removal, and confinement governs context access. Formalizing these operations lets the desired guarantees apply while multiple components evolve together rather than only when one isolated component is loaded. The fiber gives the calculus a place to represent ongoing component state, while the surrounding operations describe how components enter, interact with, and leave the composed system. This packages the earlier effect and coeffect ideas into an operational unit that can participate in formal runtime semantics. The important qualification is that these claims belong to the formal model and its stated assumptions; the article should not generalize them to every existing plugin architecture.
The formal development establishes system-level guarantees including preservation, temporal composability, spatial composability, progress, and confluence. Preservation keeps execution within the intended formal discipline. Temporal composability captures recoverable removal, while spatial composability captures reactive dependency management.
Progress addresses continued execution, and confluence addresses agreement of compatible execution paths under the calculus's equivalence. These are the formal payoff of combining reversible effects, reactive coeffects, and mediated context. They should be read as properties of the calculus described in the paper, not as a claim that arbitrary plugin systems automatically possess these guarantees. The formal results depend on the model and assumptions developed by the authors. The important qualification is that these claims belong to the formal model and its stated assumptions; the article should not generalize them to every existing plugin architecture.
Cordis is the implementation described in the paper. Its architecture mirrors the calculus: effect tracking records reversible environmental changes; coeffect operations handle environmental requirements; component lifecycle and context access expose the runtime model; and the component loader supports declarative configuration and reconciliation.
The resulting flow is declare → resolve → activate → track effects → reconcile changes → reverse effects when removed. This mapping shows where the theory appears in an engineering system. Cordis is presented as an implementation of the spatiotemporal-composability model, so its concrete mechanisms correspond to the abstract operations rather than replacing them with an unrelated plugin API. The implementation is easiest to understand after the calculus because each runtime feature has a conceptual role. The important qualification is that these claims belong to the formal model and its stated assumptions; the article should not generalize them to every existing plugin architecture.
Hot module replacement makes the benefit concrete. A live configuration changes so that one component should be replaced. Instead of restarting the whole process, the runtime reconciles the component set: the old component can have its tracked effects reversed, its dependency requirements can be reevaluated, and the replacement can activate while unrelated components remain alive.
This is the fine-grained alternative to a process restart. Its practical ingredients are declarative reconciliation, reversible effects, and reactive dependency handling. Replacement is expressed as a change to the desired component configuration and then handled through the same lifecycle machinery, so the surrounding runtime does not have to be treated as disposable merely because one component changed. The example connects the abstract guarantees directly to a familiar live-development operation. The important qualification is that these claims belong to the formal model and its stated assumptions; the article should not generalize them to every existing plugin architecture.
The paradigm compresses into one chain: declare requirements → mediate a shared context → transform the context with reversible effects → retain inverses for removal → classify context changes against coeffect specifications → activate or deactivate components reactively → rely on independence and commutativity for interleaving → reconcile live configurations.
Cordis implements this model. The paper also discusses system boundaries, service multiplexing, sandboxing and access control, language independence, component granularity and mutual dependencies, dependency typing and versioning, and co-design with languages and operating systems. The reusable mental model is: a plugin is a component with reversible effects and declared, reactively resolved dependencies. That connects the time dimension, the space dimension, and the unified context. The important qualification is that these claims belong to the formal model and its stated assumptions; the article should not generalize them to every existing plugin architecture.
