# A Programming Paradigm for Spatiotemporal Composability. Cordis > **Cikk:** Yifan Shi, Wei Zhang (Peking University), Tianyi Cui (DeepSeek-AI): *A Programming Paradigm for Spatiotemporal Composability* — 88 oldalas formális tanulmány (Section 1–8, 124 hivatkozás) > **Dátum:** 2026-08-17 (feldolgozás) > **Forrás:** (efemer gyorsítótár; a feltöltött PDF a takarítás óta nincs meg) ⚠️ (~2.1 MB) > **Wiki raw:** ## Összegzés A **Cordis** a DeepSeek-AI és a Peking University közös, 88 oldalas formális tanulmánya, amely egy új programozási paradigmát vezet be a **dinamikus kompozíció** problémájára. A paradigmát a klasszikus algebraic effects és coeffects fogalmak futásidejű mechanizmusokká emelésével építi fel: a **revertible effects** révén minden kontextus-mutációhoz automatikusan generálódik inverz, a **reactive coeffects** révén pedig minden függőség-deklaráció reaktívan újrafeloldódik, amikor a szolgáltatók betöltődnek vagy eltávolítódnak. A két mechanizmust a Γ∞ típusegyesítés és az observational equivalence fogalma kapcsolja össze egyetlen kontextus-paradigmává. A cikk formális kalkulust (komponensek, rostok, registry, 10 lifecycle szabály: Preservation Theorem 59, Recovery exactness Theorem 61, Ordering Theorem 63, Progress Theorem 66, Confluence Theorem 73) és gyakorlati implementációt (TypeScript meta-framework, deklaratív component loader HMR-rel, Koishi case study 4000+ pluginnal) is bemutat. A legfontosabb gyakorlati üzenet: a Cordis a DeepSeek-AI saját önfejlesztő agent harness-ének formális alapjaként szolgál — a temporal garancia (teljes recovery rapid komponens-csere alatt) és a spatial garancia (dependencia koordináció gyakori topológiai változás alatt) együttesen strukturális, nem konvenció-alapú Spatiotemporal Composability-t ad. --- ## 1. A cikk célja és kontextusa A dinamikus kompozíció (azaz egy futó rendszer komponenseinek biztonságos betöltése, cseréje és eltávolítása) a modern szoftverarchitektúrák egyik legnehezebb problémája. A mai gyakorlatban ezt vagy **durva granularitással** oldják meg (a teljes folyamatot újraindítják, mint a Kubernetes, Borg, konténer-orchestráció), vagy **fejlesztői fegyelemre** bízzák (plugin lifecycle callback-ek, useEffect cleanup, OSGi unload metódusok), az utóbbi megközelítés **empirikusan szivárog**: elfelejtett cleanup csendben erőforrás-szivárgást okoz. A cikk egy **programozási paradigmát** javasol, amely a határt a két véglet között húzza meg: az **effektusok és ko-effektusok** futásidejű nyomon követésével strukturális garanciát ad a komponens-eltávolítás teljes visszafordítására, anélkül, hogy a fejlesztőnek bármilyen cleanup-kódot kellene írnia. A cikk szerzői között van **Tianyi Cui a DeepSeek-AI-tól**, ami jelzi, hogy a DeepSeek ezt a meta-frameworköt (**Cordis**) a gyakorlatban is alkalmazza, vélhetően az önfejlesztő agent harness-ek belső komponenskezelésére. A tanulmány 8. szakaszában explicit validációs terepként említi az **"self-evolving agent harnesses"** forgatókönyvet. --- ## 2. A két alapfogalom: revertible effects és reactive coeffects A cikk a klasszikus számítástudományi fogalmakat (algebraic effects, coeffects. Plotkin & Power 2001, Petricek-Orchard-Mycroft 2013) emeli át futásidejű mechanizmusokká. ### 2.1 Revertible effects, időbeli komponálhatóság Minden kontextus-mutációhoz a fejlesztő **inverz függvényt** szolgáltat (pl. `set` ↔ `delete`, `open` ↔ `close`, `malloc` ↔ `free`). A futásidő az inverzeket egy **akkumulátorba** komponálja LIFO sorrendben, és a komponens eltávolításakor **automatikusan** lejátssza őket, így a kontextus visszatér a komponens betöltése előtti állapotába (Theorem 7). A kulcs: az inverz nem a rendszer kötelessége, hanem a **fejlesztő szolgáltatja az atomikus hatáshoz**, és a kompozit hatás inverze **automatikusan következik kompozícióból**. Ez a React `useEffect` cleanup-pal szemben az, hogy ott a hatás törzsében **nem lehet aszinkron vagy iterátor**, itt lehet. A Cordis hatás egy **delimált continuation** (James & Sabry 2011), a `yield` operátor formájában, ami natívan támogatott a modern nyelvekben. A `ctx.effect(callback)` primitív az `Algorithm 1`-ben: a callback egy iterátor, minden lépésben szolgáltat inverzet, a futásidő egy `execute` függvényben hajtja végre, és az inverzeket egyetlen kompozit dispose függvénnyé foldolja. A `dispose` önmaga is `ctx.effect` hívás, ami rekurzív struktúrát ad, a gyerek-hatás inverze a szülő kontextusra hat. ### 2.2 Reactive coeffects, térbeli komponálhatóság Egy komponens **deklarálja** a függőségeit (pl. "adatbázis kell", "logger kell"). A futásidő ezt a specifikációt (a `d` halmazt) a kontextus változásai ellenében **folyamatosan kiértékeli**: - **activating** transition (dependencia megjelent) → betölti a komponenst - **deactivating** transition (dependencia eltűnt) → eltávolítja (inverzeket futtatja) - **neutral** transition → nincs teendő Ez a **Dependency Inversion** távoli rokona, de a különbség lényeges: míg a Spring/Angular DI egyszer a boot-oláskor köt, a Cordis **futásidőben folyamatosan újraköt**, ha kicseréled az adatbázis-szolgáltatót, csak az érintett komponensek aktiválódnak újra. A `notify` mechanizmus (`Algorithm 3`) minden egyes kulcskötés-változásra végigmegy az aktív rostokon, és akinél a kulcs a `fiber.inject`-ben van, meghívja a `refresh`-et (`Algorithm 5`). A frissítés idempotens, így a neutrális változások ártalmatlanok. ### 2.3 Isolation és interception A `Σ_iso` kontextus (`Definition 28`) egy **két-rétegű feloldást** vezet be: a `𝜌: K ⇀ R` realm-tábla, és a `𝜎: R ⇀ Vᵣ` realm-szerinti értéktábla. Ugyanaz a kulcs különböző realm-ekben más értékre oldódik fel, ez a **multi-tenant rendszerek**, **teszt-sandboxok** és **komponens-sandboxok** alapja. A `Σ_inter` kontextus (`Definition 30`) **interception**-t ad: a kulcshoz monoid-metadátát lehet csatolni, és a lekéréskor a kontextus saját és a komponens deklarált metadátáját monoid-művelettel merge-eli. Ez a **policy enforcement** alapja: az adatbázis-szolgáltató maga nem tudja, hogy egy adott komponens csak olvashat, a kontextus interception mondja meg neki. --- ## 3. A kontextus-paradigma: Γ∞ és az egységes típus A `Section 3.3` a két részt egyesíti: `Γ∞ ≔ μΓ. Γ × (Γ → Γ) × Σ`, rekurzív típus, ahol Γ a hatás-kontextus, Γ → Γ az akkumulátor, Σ a ko-effektus kontextus. A komponensek ezen a típuson hatnak, és a `Σ` tetszőleges típusú lehet (`𝒱ᵏ`), tehát **minden megosztott állapot** kódolható ko-effektusként. Az **observational equivalence** (`Definition 33`) a Σ ko-effektusokra épül: két állapot akkor ekvivalens, ha azonos kulcsokra azonos (a kulcs saját ≃ᵏ relációjában) értékeket kötnek. Ez az egyenlőség pótolja a fizikai állás (heap layout, generatív nevek) visszaállíthatatlanságát, és az egyenlőségeket ≃-re cserélve a Theorem 7 (recovery exactness) ≃-ben is igaz marad (`Lemma 38`). Az **independence** (`Definition 19`): két hatás független, ha minden transzformációjuk kommutál, és egyikük inverze sem zavarja a másik által szolgáltatott inveret. Ez a kulcsa a globális temporális komponálhatóságnak (egy komponens inverze csak a saját hatását vonja vissza, még ha mások is közben léptek). **Theorem 42** kimondja: ha minden kulcs kommutatív (minden művelet független minden másiktól), akkor a ko-effektus-mediált hatásfüggvények függetlenek. Ez a kulcsa annak, hogy **a kompozíció skálázódik**: a komponensek száma nem befolyásolja a globális garanciát. --- ## 4. A dinamikus kompozíció kalkulusa ### 4.1 Komponensek és rostok (fiber) Egy komponens hármas `(d, p, e)`: a deklarált ko-effektus specifikáció (`d`), a szolgáltatott kulcsok halmaza (`p`), és a witnessed effect function (`e`). A rost (`fiber`) ennek egy **pillanatfelvétele** a futó rendszerben: a `(d, p, e, π, σ, τ, θ)` tuple, ahol π a szülő rost, σ a saját ko-effektus tábla, τ a retired flag, θ a lifecycle állapot. A registry a rostok táblázata (`Fγ : N ⇀ F`), és a Σ ko-effektus kontextust **levezetjük** a registryből: `σγ ≔ ⋃{σ� | m ∈ dom(Fγ), θₘ = Active}` (Definition 45). Tehát nincs központi ko-effektus tábla, az **aktív rostok egyesítése** adja. Minden kulcsnak **egy provider**-e van (a `p ∩ pₘ = ∅` single-source discipline miatt). ### 4.2 A kétállapotú alap A lifecycle a 4.2 szakaszban: Inactive ↔ Active. Két szabály: - **L-Reload**: ha θ = Inactive és target(γ, n) ≠ ⊥ → futtatja `e`-t, felhalmozza az inverzeket, kommitálja a nézetet (`ω = target`) - **L-Unload**: ha θ = Active(g, ω) és target(γ, n) ≠ ω → alkalmazza `g`-t (LIFO inverz sorrendben), eldobja ω-t A **target view** (`Definition 46`) egy leképezés `dₙ → N`, minden deklarált kulcshoz megadja a jelenlegi providert (vagy ⊥-t, ha nincs). A rendszer akkor **quiescent** (Definition 42), ha minden rost nézete megegyezik a target nézetével. ### 4.3 A kibővített lifecycle: in-progress tranzíciók A valódi runtime-ok nem atomiak és nem szinkronok. A 4.3 szakasz három dolgot bocsát ki: 1. **Withdrawal** (4.3.1): A L-Unload **guard**-ja, `¬reliedₙ(γ)`, biztosítja, hogy a provider ne vonja vissza a kulcsot, amíg valamely fogyasztó még aktív (az L-Leave kétlépcsős teardown). Ez teremti meg azt az **intervallumot**, ami alatt a fogyasztó a saját teardownját futtathatja. 2. **Iteration** (4.3.2): Az effect iterator (`Definition 51`) rekurzív típus, `Γ → Γ × (Γ → Γ) × Maybe(iter)`. A `Maybe` continuation jelzi a yield-határt; a host bármikor **divertelhet** (L-Divert), ha a target nézet eltolódott. 3. **Asynchrony** (4.3.3): Az iteráció `Future`-t ad vissza; az in-flight iteráció **inerciális**, landolnia kell, mielőtt a rendszer másra reagál. Ez adja a "kölcsönös láncolás" viselkedését. 4. **Failure** (4.3.4): Az iteráció `Either(Ξ, Γ × (Γ → Γ) × Maybe(iter))`, `L-Raise` kezeli a hibát, és az akkumulátor visszafordítja a részleges hatásokat. ### 4.4 A metaelmélet - **Preservation** (Theorem 59): a 10 szabály megőrzi a registry well-formednességét. - **Recovery exactness** (Theorem 61): egy rost akkumulátora ≃-ben visszaadja azt az állapotot, amit akkor kapnánk, ha a rost sosem futott volna, **bármi** történik közben. - **Ordering** (Theorem 63): a guard biztosítja, hogy egy komponens csak akkor aktiválódik, ha minden függősége elérhető, és egy provider csak azután vonja vissza a kulcsot, miután minden fogyasztó deaktiválódott. - **Progress** (Theorem 66): nincs deadlock (a � precedencia reláció aciklikussága mellett); a S(n) ≤ (K+4)(V(n)+1) komplexitású termináció. - **Confluence** (Theorem 73): a rendszer **mindig ugyanoda quiescel**, függetlenül attól, hogy a tranzíciók milyen sorrendben futottak, ez az, ami lehetővé teszi, hogy a Cordis alkalmazásról **úgy gondolkodjunk, mintha statikusan lenne összerakva**. --- ## 5. Implementáció: Cordis meta-framework ### 5.1 Core library Három tier, lentről fölfelé: 1. **Effect tracking** (`Algorithm 1`): `ctx.effect(callback)` primitív, ami iterátorként hajtja végre a callbackot, és dispose függvényt ad vissza. 2. **Coeffect operations** (`Algorithm 2`): `ctx.get(key)`, `ctx.set(key, value)`, `ctx.isolate(key, realm)`, `ctx.intercept(key, metadata)`. A set egy `ctx.effect`, így automatikusan tracked. 3. **Component lifecycle** (`Algorithm 4-5`): `ctx.use(component, config)` egy rostot hoz létre. A `refresh` újraszámolja a target nézetet és elindítja a reload/unload taskot. A `Table 2` a 18 elméleti konstrukció és a runtime implementáció közötti megfeleltetés, ez adja a meta-framework státuszt: Cordis **nem domain-specifikus** (nem web routing, nem ORM), hanem **univerzális dinamikus kompozíció**. ### 5.2 Component loader és HMR A `loader` egy **deklaratív konfigurációs réteget** ad: az orchestrátor egy perzisztens adatszerkezetben írja le a kívánt kompozíciót (`Definition 74` entry-k: id, url, isolate, intercept, config, disabled), és a loader a változásokat imperatív rost-műveletekre fordítja. A **reconciliation** inkrementális: Theorem 73 miatt a quiescens állapot a végső konfiguráció függvénye, Corollary 62 miatt egy entry eltávolítása nem zavarja a többieket. A **Hot Module Replacement** (`Algorithm 8-10`) három fázisban működik: 1. **Module classification**: a stashed fájlok dependency subgraph-ját accepted/declined halmazokra bontja (ciklikus függőség → declined). 2. **Stale-entry detection**: csak azokat az entry-ket jelöli meg, amelyeknek a függőségi fája érint accepted modult. 3. **Transactional reload**: eldobja a régi rostokat és újrainstantiálja az accepted modulokból; ha bármelyik import elbukik, a backupból rollbackel. ### 5.3 Koishi case study A **Koishi** egy nyílt forráskódú chatbot keretrendszer, amely 4+ év alatt **4000+ közösségi plugint** halmozott fel (IM adapterek, DB driverek, admin konzolok). A cikk négy érvényesítési pontot emel ki: 1. **Expressiveness**: a teljes gyártási rendszer kifejezhető Cordis primitívokkal, a Koishi csak a chatbot-domain szókincset adja hozzá. 2. **Generality**: ugyanaz a modell működik szerver-oldalon (chatbot) és a böngészőben (webkonzol), más domain, más futásidejű környezet, ugyanaz a Cordis. 3. **Temporal composability overhead nélkül**: a plugout a konzolról → azonnali, helybeni hatás-visszavonás. A HMR a save-re azonnal újratölti a plugint, megtartva a cache-állapotot és az élő kapcsolatokat. 4. **Spatial composability nyílt ökoszisztémában**: az IM adapterek biztosítják a messaging platformokat, a DB driverek a perzisztens tárolást, a feature pluginek ezeket deklarálják, a szerzők **nem koordinálnak**, csak a ko-effektus kulcsot egyeztetik. A **threats to validity**: egy ökoszisztéma, egy hoszt nyelv, megfigyeléses (nem kontrollált összehasonlítás). Létezés- és adaptáció-validáció, nem kvantitatív. --- ## 6. Diskusszió: rendszerhatár, sandboxing, nyelvek ### 6.1 System boundary, acquisition vs emission A határ **lokáció-szintű**, nem médium-szintű: egy memóriaregió a határon belül van, ha a rendszer kizárólagosan írja és vissza tudja állítani; kívül, ha más folyamatok is írják. A ko-effektus **mozgatja a határt**: ha egy lokációt ko-effektusként reifikálunk, a rendszer képes lesz visszaállítani. Minden művelet két fázisban megy végbe: **acquisition** (a határon belül, revertálható) + **emission** (a határon kívül, nem revertálható). A visszaállítás két stratégiája: **withhold** (a kibocsátás késleltetése az output commit probléma) vagy **compensation** (kompenzáló akció, ami ≃-nál durvább ekvivalenciával állítja vissza az állapotot, pl. fájl törlése). ### 6.2 Service multiplexing, service broker A ko-effektus modell natívan támogatja a **service broker** mintát: egy központi szolgáltatás, ami több providert is befogad, és a kéréseket policy (round-robin, least-loaded, latency-weighted) alapján osztja szét. Ez adja a **load balancing**-ot, **rolling updates**-et (új provider betöltése, forgalom-átirányítás, régi unload), és a **cross-process invocation**-t (RPC-n keresztül, async contract). ### 6.3 Capability-based access control + sandboxing A dependency access mechanism már egy **capability-based security** forma: a komponens csak az általa deklarált ko-effektusokhoz fér. Az interception metaadat-policy-ként szolgál (pl. read-only DB hozzáférés egy közösségi pluginnak). A **sandboxing** (amikor a komponens kódja nem megbízható) a nyelv-szintű határokon túlmutat. WebAssembly, OS process, software fault isolation kell hozzá. ### 6.4 Language independence A kontextus-paradigma nyelv-agnosztikus, de a host nyelvnek két dolgot kell tudnia: 1. **Closure** (az inverz first-class érték kell hogy legyen) 2. **Dynamic module registry** (a modulok betölthetők és eltávolíthatók futásidőben) A 4. szinten a nyelvek: managed runtime (Node.js CommonJS/ESM cache) ↔ natív kód (dlopen/dlclose) ↔ WebAssembly (managed vagy natív embedder). A ko-effektus oldalon: typeclasses (Haskell), traits (Rust), TypeScript module augmentation a típus-szinten; Proxy (JS), descriptor protocol (Python), vagy metaprogramming (Rust proc macros, Scala macros, Zig comptime) a mediation-re. ### 6.5–6.7 Mutual dependencies, typing, OS co-design A **ciklikus függőségek** a `⊲` reláció ciklussá válásával járnak, de a futásidő ezt jelenti (mindkét komponens örökre Inactive), szemben a concurrent deadlockkal, ami schedule-függő. A dekompozíció (kétirányú kölcsönhatás → két egyirányú integrációs komponens) mindig lehetséges, de a komponensek számát a négyzetével növeli. A **dependency typing** a kulcs-azonosítás vs. strukturális kompatibilitás problémája: a kulcs-ütközés (két provider ugyanazt a kulcsot használja, de más interfészt) és az interface drift (verzióváltáskor a consumer nem veszi észre) ellen három megoldás: key namespacing, peer dependencies, structural compatibility, nyitott probléma. Az **OS co-design** víziója: ha az OS a ko-effektust első osztályú állampolgárként kezeli (minden erőforrás ko-effektusként érhető el, a sandboxing natív, a reifikáció a kernel szintjén történik), akkor a komponensek **deklaratív formában** írhatják le, mit érnek el, és az OS garantálja, hogy nem érnek el mást. --- ## 7. Related work és a paradigma pozíciója A cikk a 124 hivatkozással 4 tengely mentén pozicionálja magát: 1. **Effect systems**. ZIO/Effect-TS/fp-ts monadic embedding vs. Cordis overlay; Effekt capability-based scope-based vs. Cordis runtime tracking; Heunen et al. reversible arrows denotációs vs. Cordis runtime inverzek; Orchard et al. graded modal types statikus vs. Cordis dinamikus. 2. **Programming paradigms**. COP (rétegek aktiválása) vs. Cordis (komponensek revertálható betöltése); AOP (oblique pointcut-ok) vs. Cordis (deklarált ko-effektusok). 3. **Temporal composability**. DSU/HMR (state forward migration, kézzel írt transzformációk) vs. Cordis (automatikus revertálás); STM (statikus scope rollback) vs. Cordis (dinamikus lifecycle); Nooks/shadow drivers (kernel-szintű reclamation) vs. Cordis (komponens-szintű, általános). 4. **Spatial composability**. Spring/DI/Angular (boot-time wiring) vs. Cordis (runtime reactive); OSGi Declarative Services/iPOJO (availability-reactive, kézzel írt cleanup) vs. Cordis (automatikus revert); FRP/signals (value-level reactivity) vs. Cordis (component-level, async lifecycle). A **kulcsszó**: Cordis **egyszerre** kínál futásidejű revertálhatóságot **és** futásidejű resettelhetőséget, ez a kombináció hiányzik minden más rendszerből. --- ## 8. Következtetés és az agent harness validáció A cikk a kontextus-paradigmát és a Cordis-t **létező megoldásként** mutatja be: a Koishi 4000+ pluginnal bizonyítja, hogy a dinamikus kompozíció skálázódik production környezetben. A **jövőbeli validáció** iránya kifejezetten az önfejlesztő agent harness-ek: - **Temporal garancia** (teljes recovery rapid komponens-csere alatt), az agent harness másodpercenként cserélheti a komponenseit - **Spatial garancia** (dependencia koordináció gyakori topológiai változás alatt), a harness topológiája futásidőben alakul A DeepSeek-AI szerzői tehát **saját use-case-ük validációs anyagaként** publikálják a Cordis-t: a Cordis az ő saját harness engineering-jük formális alapja. Ez összhangban van a Henky MEMORY-ban rögzített "deepseek harness audit" kontextussal. A két kulcs-claim: 1. **Teljes recovery invariáns**, nem a fejlesztő fegyelmén múlik 2. **Reaktív re-feloldás**, nem a boot-time wiring-on múlik Ezek együttesen jelentik a **Spatiotemporal Composability** garanciáját: a rendszer **térben és időben** is biztonságosan komponálható, és ez a garancia strukturális, nem konvenció. --- ## Forrás és meta **Forrás:** (efemer gyorsítótár; a feltöltött PDF a takarítás óta nincs meg) ⚠️ (~2.1 MB, 88 oldal, 2330 sor kinyert szöveg) **Topic:** `ai-automation.md` (DeepSeek engineering + AI policy convergence pont) **Feldolgozás:** saját kiolvasás (PDF szövegkinyerés a `read_file` eszközzel) → kézi magyar összefoglaló → tanulmanyok pipeline patch.