@claudetools/tools 0.8.11 → 0.9.0

package/docs/research/2026-01-02-computation-foundations.md

@@ -0,0 +1,564 @@
+# Alternative Computational Foundations: Beyond Lambda Calculus
+
+**Research Date:** 2026-01-02
+**Question:** Are there more fundamental computational models than lambda calculus + types + effects that could serve as a universal foundation for ALL code?
+
+## Executive Summary
+
+After investigating seven major alternative computational paradigms, the key finding is: **No single model is strictly more fundamental than lambda calculus**. Instead, there exists a landscape of **computationally equivalent but conceptually distinct** foundations, each optimising for different aspects of computation:
+
+- **Graph Rewriting Systems** (especially Interaction Nets) offer optimal reduction and intrinsic parallelism
+- **Term Rewriting Systems** provide concurrent computation as deduction
+- **Process Calculi** (π-calculus) make concurrency and mobility primitive
+- **Linear Logic** treats resources and consumption as fundamental
+- **Cellular Automata** demonstrate computational universality from minimal local rules
+- **Category Theory** (HoTT, higher categories) unify logic, types and topology
+- **Wolfram's Hypergraph Rewriting** proposes a pre-axiomatic foundation beneath mathematics itself
+
+**For AI code generation:** Lambda calculus remains the most practical foundation due to mature tooling, compositional semantics and decades of research. However, **interaction nets** and **linear types** show promise for optimal parallel execution and resource-aware code generation.
+
+---
+
+## 1. Graph Rewriting Systems
+
+### Core Concept
+Computation is graph transformation via local rewriting rules.
+
+### Key Variants
+
+#### 1.1 Lafont's Interaction Nets
+- **Foundation:** Based on classical linear logic proof nets
+- **Universality:** [Interaction Combinators](https://www.semanticscholar.org/paper/Interaction-Combinators-Lafont/6cfe09aa6e5da6ce98077b7a048cb1badd78cc76) with only **3 symbols and 6 rules** are Turing-complete
+- **Key Property:** Pure locality of interaction, strong confluence, inherent parallelism
+- **Lafont Universality:** Can encode *any* interaction net system, including Turing machines
+
+#### 1.2 Lamping's Optimal Reduction
+- **Purpose:** [Optimal lambda calculus reduction](https://dl.acm.org/doi/10.1145/96709.96711) avoiding duplicated work
+- **Mechanism:** Sharing graphs with explicit fan-in/fan-out nodes
+- **Connection:** Girard's [Geometry of Interaction](https://www.researchgate.net/publication/220997121_The_Geometry_of_Optimal_Lambda_Reduction) provides semantic foundation
+- **Implementation:** [BOHM](https://link.springer.com/chapter/10.1007/978-3-540-25979-4_11) (Bologna Optimal Higher-Order Machine) achieves efficient practical implementation
+
+### Can It Express All Computation?
+
+**Yes, with caveats:**
+- ✅ Functional computation: Multiple [encodings of lambda calculus](https://dl.acm.org/doi/book/10.5555/562684)
+- ✅ Concurrent computation: Yes via interaction net parallelism
+- ✅ Imperative: Yes via state-passing encodings
+- ⚠️ Quantum: Not naturally (requires extension)
+- ❌ Non-determinism: [Extensions required](https://www.researchgate.net/publication/238799226_Non-deterministic_Interaction_Nets)
+
+### Is It More Fundamental?
+
+**Equally fundamental, not more:**
+- Church-Turing equivalent
+- **Advantages:** Intrinsic parallelism, optimal sharing, visual/geometric intuition
+- **Disadvantages:** [Must re-establish many theoretical results](https://link.springer.com/chapter/10.1007/3-540-63172-0_35), less mature tooling
+
+### Practical for AI Code Generation?
+
+**Promising but immature:**
+- ✅ Optimal reduction could eliminate redundant computation
+- ✅ Natural parallelism valuable for concurrent code
+- ❌ Encoding functional programs is "incredibly tedious"
+- ❌ Minimal tooling/compiler infrastructure
+- ❌ Debugging/reasoning tools underdeveloped
+
+**Verdict:** Theoretically elegant, practically premature. Worth watching as [research continues](https://github.com/chemlambda/molecular).
+
+---
+
+## 2. Term Rewriting Systems
+
+### Core Concept
+Computation as equation solving via directed term rewriting.
+
+### Key System: Maude (Rewriting Logic)
+
+- **Foundation:** [Rewriting Logic](https://link.springer.com/chapter/10.1007/10721975_1) (Meseguer, 1992)
+- **Dual Reading:** Rules are both (1) local state transitions AND (2) inference rules
+- **Structure:** Theory = (Σ, E ∪ A, φ, R) where:
+  - (Σ, E ∪ A) = equational theory
+  - R = conditional rewrite rules
+  - Computation = equational simplification + rule rewriting
+
+### Expressiveness
+
+**Extremely expressive as semantic framework:**
+- Can specify many concurrent systems, languages, distributed protocols
+- [Logical framework](https://www.sciencedirect.com/science/article/pii/S0304397501001590) for representing other logics
+- Membership equational logic supports subsorts, overloading, partiality
+
+### Can It Express All Computation?
+
+**Yes:**
+- ✅ Functional: Via equational theories
+- ✅ Concurrent: State transitions are primitive
+- ✅ Imperative: Via state-passing
+- ✅ Distributed systems: Native support
+- ⚠️ Quantum: Requires extensions
+
+### Is It More Fundamental?
+
+**Equally fundamental, different perspective:**
+- Church-Turing equivalent
+- **Key insight:** Abandons "equation" reading for "dynamic transition" reading
+- **Philosophy:** Computation IS rewriting, not function evaluation
+
+### Practical for AI Code Generation?
+
+**Moderate potential:**
+- ✅ [Maude system](https://github.com/maude-lang/Maude) is mature and actively maintained
+- ✅ Strong metaprogramming via reflection
+- ✅ Natural for concurrent/distributed systems
+- ❌ Unfamiliar to most developers
+- ❌ No mainstream language adoption
+- ❌ Tooling gap compared to functional languages
+
+**Verdict:** Powerful for specification and verification, but not yet practical for general code generation.
+
+---
+
+## 3. Process Calculi (π-calculus, CSP)
+
+### Core Concept
+Computation is concurrent message-passing; network topology can change dynamically.
+
+### Key Systems
+
+#### 3.1 π-Calculus (Milner, 1990s)
+- **Primitive:** Processes and channels
+- **Key Feature:** [Channel names can be communicated](https://en.wikipedia.org/wiki/%CE%A0-calculus), enabling dynamic topology
+- **Universality:** [Encodes lambda calculus](https://golem.ph.utexas.edu/category/2009/08/the_pi_calculus.html) (both call-by-value and call-by-name)
+
+#### 3.2 CSP (Hoare, 1978)
+- **Focus:** Communicating Sequential Processes
+- **Relationship:** Predecessor to π-calculus, more static topology
+
+### Can It Express All Computation?
+
+**Yes:**
+- ✅ Functional: Via [encoding lambda calculus](https://en.wikipedia.org/wiki/%CE%A0-calculus) ("Functions as Processes")
+- ✅ Concurrent: Fundamental primitive
+- ✅ Imperative: Via process state
+- ✅ Mobile systems: Dynamic topology native
+- ⚠️ Quantum: Extensions exist (quantum process algebras)
+
+**Expressiveness hierarchy:**
+- Synchronous π > Asynchronous π
+- π-calculus = Higher-order π-calculus
+- Ambient calculus > π-calculus
+
+### Is It More Fundamental?
+
+**For concurrency, arguably yes:**
+- [Process calculi](https://en.wikipedia.org/wiki/Process_calculus) arose from need to model concurrency explicitly
+- Lambda calculus is "most readily understood as sequential computation"
+- **Philosophical shift:** From functions to interactions
+
+**However:** Sangiorgi & Walker note π-calculus is "only a stepping-stone" toward a complete theory of mobile systems—**not yet the fundamental theory**.
+
+### Practical for AI Code Generation?
+
+**Limited:**
+- ✅ Excellent for concurrent systems, protocols
+- ✅ Used in [cryptographic protocol reasoning](https://en.wikipedia.org/wiki/%CE%A0-calculus) (spi-calculus, applied π)
+- ❌ Too minimal (like lambda calculus: no primitives for numbers, booleans, control flow)
+- ❌ Encoding practical programs is tedious
+- ❌ No mainstream programming language adoption
+
+**Verdict:** Influential theoretically (actors, Erlang), but not a practical universal foundation.
+
+---
+
+## 4. Linear Logic
+
+### Core Concept
+Logic where resources are consumed, not endlessly reproducible.
+
+### Foundation (Girard, 1987)
+
+- **Key Insight:** [Treat assumptions as finite resources](https://plato.stanford.edu/entries/logic-linear/)
+- **Mechanism:** Restricts contraction/weakening to formulas marked with modals
+- **Computational Reading:** State transitions and resource consumption
+
+### Proofs-as-Programs
+
+- **Curry-Howard:** Linear logic proofs → Resource-aware lambda calculus
+- **Benefits:** Finer control over evaluation order and storage allocation
+- **[Proof Nets](https://www.brics.dk/LS/96/6/BRICS-LS-96-6.pdf):** Cut elimination in linear time (MLL)
+
+### Can It Express All Computation?
+
+**Yes:**
+- ✅ Functional: Via refinement of lambda calculus
+- ✅ Imperative: Via [linear state transitions](https://plato.stanford.edu/entries/logic-linear/)
+- ✅ Concurrent: Via process interpretations
+- ✅ Quantum: [Natural fit](https://www.sciencedirect.com/science/article/abs/pii/S0303264718301102) (no-cloning aligns with linearity)
+
+### Is It More Fundamental?
+
+**More refined, not more fundamental:**
+- Church-Turing equivalent
+- **Advantage:** Makes resource usage *explicit* in type system
+- **Philosophy:** Truth → State transitions
+- **Applications:** Concurrency, quantum computing, [separation logic](https://plato.stanford.edu/entries/logic-linear/), implicit complexity
+
+### Practical for AI Code Generation?
+
+**Emerging practical value:**
+- ✅ [Rust's borrow checker](https://medium.com/@martriay/rust-and-linear-types-a-short-guide-4845e9f1bb8f) inspired by linear/affine types
+- ✅ [ATS language](https://dl.acm.org/doi/10.1145/3720492) uses linear types for systems programming
+- ✅ Memory safety without garbage collection
+- ⚠️ [Challenging to use](https://faultlore.com/blah/linear-rust/): "Rust lacks 'proper' support for this kind of type"
+- ❌ Requires sophisticated type system (complex for AI to generate)
+
+**Verdict:** **Highest practical potential** for systems programming code generation. Linear types are the future of resource-aware languages.
+
+---
+
+## 5. Cellular Automata
+
+### Core Concept
+Computation emerges from local rules on spatial arrays.
+
+### Key Result: Rule 110
+
+- **Discovery:** [Matthew Cook proved Rule 110 is Turing-complete](https://en.wikipedia.org/wiki/Rule_110) (2004)
+- **Method:** Encodes cyclic tag systems → 2-tag systems → Turing machines
+- **Significance:** Among 88 elementary CAs, only Rule 110 has direct universality proof
+- **Simplicity:** Emerges from *single local rule* applied to binary cells
+
+### Wolfram's Principle of Computational Equivalence
+
+- **Claim:** [All non-trivial systems are computationally equivalent](https://www.foundalis.com/mat/pce/pce.htm) (Class 4 behaviour)
+- **Implication:** Universality is "extremely common" in nature
+- **Controversy:** Principle is philosophical, not rigorously proven
+
+### Can It Express All Computation?
+
+**Yes, but impractically:**
+- ✅ Functional: Via encoding Turing machines
+- ✅ Imperative: Via state evolution
+- ⚠️ Concurrent: Implicit in parallelism, but not structured
+- ❌ Quantum: Not naturally
+- ❌ High-level abstractions: Essentially impossible
+
+### Is It More Fundamental?
+
+**Physically fundamental, computationally equivalent:**
+- **Physics perspective:** May model fundamental physical processes
+- **Computation perspective:** Church-Turing equivalent
+- **Philosophical:** Shows universality arises from minimal rules
+
+### Practical for AI Code Generation?
+
+**Completely impractical:**
+- ❌ Encoding even simple programs is extraordinarily complex
+- ❌ No compositional structure
+- ❌ No debugging or reasoning tools
+- ❌ Space/time efficiency catastrophic for practical algorithms
+
+**Verdict:** Fascinating theoretically, utterly useless for code generation.
+
+---
+
+## 6. Category Theory (Operads, Higher Categories, HoTT)
+
+### Core Concept
+Computation as structure-preserving transformations; types as spaces.
+
+### Key Frameworks
+
+#### 6.1 Homotopy Type Theory (HoTT)
+
+- **Foundation:** [Martin-Löf intensional type theory + homotopy interpretation](https://homotopytypetheory.org/)
+- **Key Insight:** Propositional equality = homotopy; type isomorphism = homotopy equivalence
+- **Advantages:**
+  - Treats ∞-groupoids natively
+  - [Good computational properties](https://ncatlab.org/nlab/show/homotopy+type+theory)
+  - Unifies logic, types and topology
+
+#### 6.2 Higher Categories
+
+- **Purpose:** [Replace equalities with explicit arrows](https://en.wikipedia.org/wiki/Higher_category_theory)
+- **Applications:** Topology, algebraic geometry, mathematical physics
+- **Relationship to Types:** [Type theory ↔ (∞,1)-category theory](https://ncatlab.org/nlab/show/relationship+between+type+theory+and+category+theory)
+
+#### 6.3 Operads
+
+- **Purpose:** Encode compositional structure
+- **Applications:** [Algebraic quantum field theory](https://arxiv.org/abs/2305.03372), string diagrams
+- **Connection:** N-sesquicategories as algebras over globular operads
+
+### Can It Express All Computation?
+
+**Yes:**
+- ✅ Functional: Via lambda calculus interpretation
+- ✅ Dependent types: Native in HoTT
+- ✅ Concurrent: Via categorical semantics
+- ⚠️ Imperative: Via monads/effects
+- ✅ Quantum: Via dagger categories
+
+### Is It More Fundamental?
+
+**Meta-foundational:**
+- **Not competing:** Category theory is a *language for foundations*, not a computational model
+- **Role:** [Provides semantics for type theory](https://ncatlab.org/nlab/show/relationship+between+type+theory+and+category+theory)
+- **Unifying:** "Computational trinitarianism" (propositions-types-categories)
+
+### Practical for AI Code Generation?
+
+**Long-term foundation, not near-term tool:**
+- ✅ [Type-theoretic model categories](https://ncatlab.org/nlab/show/type-theoretic+model+category) ensure all suitable (∞,1)-categories can present HoTT
+- ✅ HoTT has proof assistants (Agda, Coq)
+- ❌ Extremely abstract—requires expert knowledge
+- ❌ Gap between theory and practical programming languages
+- ❌ Not designed for imperative/systems code
+
+**Verdict:** Foundational research with century-scale impact, but not a practical code generation target.
+
+---
+
+## 7. Wolfram's Hypergraph Rewriting (The Ruliad)
+
+### Core Concept
+Physics and mathematics emerge from rewriting abstract hypergraphs.
+
+### The Ruliad
+
+- **Definition:** [Entangled limit of all possible computations](https://writings.stephenwolfram.com/2021/11/the-concept-of-the-ruliad/)
+- **Construction:** Apply all possible computational rules in all possible ways
+- **Uniqueness:** The Ruliad is unique; descriptions (coordinate systems) vary
+- **Implication:** Physics and computation share a single abstract structure
+
+### Hypergraph Rewriting
+
+- **Primitives:** Nodes ("atoms of space"), hyperedges
+- **Dynamics:** Local rewriting rules
+- **Emergence:**
+  - Spatial hypergraph → space (large-scale limit)
+  - Causal graph → spacetime
+  - [Continuum limit obeys Einstein's equations](https://www.wolframscience.com/metamathematics/the-case-of-hypergraphs/)
+
+### Multicomputational Paradigm
+
+- **Key Idea:** [Multiple computation paths explored simultaneously](https://philsci-archive.pitt.edu/22519/1/Ruliad.pdf)
+- **Quantum connection:** Multiway evolution → quantum superposition
+- **Observers:** Different "slices" of the Ruliad correspond to different physical laws
+
+### Can It Express All Computation?
+
+**By construction, yes:**
+- **Universal by definition:** The Ruliad contains *all* computations
+- Can be described via Turing machines, hypergraphs, or any computational system
+- All descriptions lead to the same limiting object
+
+### Is It More Fundamental?
+
+**Claims to be pre-foundational:**
+- **Radical claim:** Goes ["below axiomatic mathematics"](https://www.wolframscience.com/metamathematics/going-below-axiomatic-mathematics/)
+- **Physics-math unification:** Single structure underlies both
+- **Criticism:** Highly speculative; lacks rigorous mathematical development
+
+### Practical for AI Code Generation?
+
+**Completely impractical:**
+- ❌ No compilers, tools, or languages
+- ❌ Encoding programs would be like encoding in Rule 110—absurd
+- ❌ Research focus is fundamental physics, not software engineering
+- ❌ [Technical research](https://bulletins.wolframphysics.org/) is highly abstract
+
+**Verdict:** Fascinating cosmological/philosophical framework, zero practical programming utility.
+
+---
+
+## 8. Quantum Computation Models
+
+### Quantum Lambda Calculus
+
+- **Foundation:** [Linear lambda calculi for quantum computation](https://arxiv.org/abs/quant-ph/0307150)
+- **Equivalence:** Quantum Turing machine ↔ quantum lambda calculus
+- **No-cloning:** Handled via linear types (prevent duplication)
+- **Applications:** [Quantum Key Distribution, Quantum Fourier Transform](https://www.academia.edu/2370968/On_Quantum_Lambda_Calculi_a_Foundational_Perspective)
+
+### Expressiveness
+
+**Extension of classical computation:**
+- ✅ All classical computation + quantum superposition/entanglement
+- ✅ [Dagger compact categories](https://www.academia.edu/11324348/Higher_order_semantics_for_quantum_programming_languages_with_classical_control) provide semantics
+- ⚠️ Still Church-Turing equivalent (no hypercomputation)
+
+### Practical Impact
+
+- ❌ Quantum hardware extremely limited (2026)
+- ❌ Not relevant for classical code generation
+- ⏳ Future relevance if quantum computers scale
+
+---
+
+## Comparative Analysis
+
+| Model | Turing-Complete? | More Fundamental? | Practical for AI Codegen? | Key Advantage |
+|-------|------------------|-------------------|---------------------------|---------------|
+| **Lambda Calculus** | ✅ | Baseline | ✅ **Best** | Mature, compositional, well-understood |
+| **Interaction Nets** | ✅ | Equal (different perspective) | ⚠️ Future potential | Optimal sharing, intrinsic parallelism |
+| **Term Rewriting** | ✅ | Equal | ⚠️ Specification/verification | Concurrency native, logical duality |
+| **π-Calculus** | ✅ | Equal (concurrency-first) | ❌ Too abstract | Mobility, dynamic topology |
+| **Linear Logic** | ✅ | Equal (resource-aware) | ✅ **Growing** (Rust, ATS) | Resource safety, memory without GC |
+| **Cellular Automata** | ✅ | Equal (emergent) | ❌ Impractical | Minimal rules, physical realism |
+| **Category Theory/HoTT** | ✅ | Meta-foundational | ❌ Too abstract | Unifies logic/types/topology |
+| **Hypergraph Rewriting** | ✅ (by definition) | Claims pre-foundational | ❌ No tooling | Physics-computation unification |
+| **Quantum λ-Calculus** | ✅ | Extension | ❌ Hardware unavailable | Quantum algorithms |
+
+---
+
+## Implications for AI Code Generation
+
+### Current Reality (2026)
+
+**Lambda calculus + types + effects remains optimal:**
+
+1. **Maturity:** Decades of compiler research, optimisation, tooling
+2. **Compositional:** Easy to build complex programs from simple parts
+3. **Algebraic:** Equational reasoning enables verification
+4. **Language support:** Haskell, OCaml, Scala, Rust, TypeScript all lambda-based
+
+### Emerging Alternatives
+
+#### Linear Types (High Priority)
+- **Rust's success** proves practicality
+- **AI advantage:** Can generate memory-safe code without GC
+- **Limitation:** Type systems complex; requires sophisticated inference
+
+#### Interaction Nets (Medium Priority)
+- **Theoretical beauty:** Optimal reduction could eliminate redundant work
+- **Barrier:** Tooling gap, encoding difficulty
+- **Timeline:** 10+ years from practical use
+
+#### Process Calculi (Low Priority)
+- **Niche:** Excellent for concurrent systems, protocols
+- **General purpose:** Too low-level for most applications
+
+### What Would a "More Fundamental" Model Enable?
+
+**Hypothetically, a better foundation would:**
+1. ✅ **Unify paradigms:** Functional, imperative, concurrent, quantum
+2. ✅ **Simplify reasoning:** Fewer primitives, clearer semantics
+3. ✅ **Enable optimisation:** Automatic parallelism, resource management
+4. ✅ **Prevent bugs:** Type safety, resource safety by construction
+
+**Reality check:**
+- Interaction nets achieve (2) and (3) but fail (1) and (4)
+- Linear logic achieves (3) and (4) but complicates (2)
+- Process calculi achieve (1) but complicate (2) and (4)
+
+**Conclusion:** No single model dominates. Lambda calculus persists because it **balances** all concerns reasonably well.
+
+---
+
+## Recommendations
+
+### For AI Code Generation Research
+
+1. **Primary foundation:** Continue with lambda calculus + types + effects
+2. **Invest in linear types:** Rust-style resource safety is the future
+3. **Monitor interaction nets:** Could enable next-generation optimising compilers
+4. **Ignore cellular automata/Ruliad:** No practical path forward
+
+### For Theoretical Exploration
+
+1. **HoTT/Category Theory:** Long-term foundations for verified code
+2. **Process calculi:** Essential for distributed systems, blockchain, protocols
+3. **Quantum lambda calculus:** Prepare for post-classical hardware
+
+### For ClaudeTools Memory (CodeDNA)
+
+**Current approach is correct:**
+- Graph-based representation (AST → dependency graph) captures structure
+- Lambda calculus semantics for functional code
+- Effect systems for imperative features
+- **Future enhancement:** Add linear type annotations for Rust code generation
+
+---
+
+## Conclusion
+
+**No computational model is strictly more fundamental than lambda calculus** in the Church-Turing sense—all are equivalent in expressive power. However, **different models foreground different aspects of computation:**
+
+- **Lambda calculus:** Functions, composition
+- **Interaction nets:** Optimal sharing, parallelism
+- **Linear logic:** Resources, memory safety
+- **Process calculi:** Concurrency, mobility
+- **Cellular automata:** Emergence from minimal rules
+- **Category theory:** Structural abstractions
+- **Hypergraph rewriting:** Physics-computation duality
+
+**For AI code generation in 2026:** Lambda calculus + types + effects remains the sweet spot. **Linear types** are the most promising near-term evolution, as evidenced by Rust's success in systems programming.
+
+The search for a "more fundamental" model is valuable theoretically—**interaction nets** and **linear logic** offer genuine insights—but practically, we're optimising for the wrong metric. The question isn't "what's most fundamental?" but **"what enables the best balance of expressiveness, safety, performance and tooling?"**
+
+On that measure, **lambda calculus won decades ago**, and only linear types have mounted a credible challenge.
+
+---
+
+## Sources
+
+### Graph Rewriting Systems
+- [Interaction Combinators (Lafont)](https://www.semanticscholar.org/paper/Interaction-Combinators-Lafont/6cfe09aa6e5da6ce98077b7a048cb1badd78cc76)
+- [Interaction nets (Wikipedia)](https://en.wikipedia.org/wiki/Interaction_nets)
+- [Optimal Lambda Calculus Reduction (Lamping)](https://dl.acm.org/doi/10.1145/96709.96711)
+- [Geometry of Optimal Lambda Reduction](https://www.researchgate.net/publication/220997121_The_Geometry_of_Optimal_Lambda_Reduction)
+- [Efficient λ-Evaluation with Interaction Nets](https://link.springer.com/chapter/10.1007/978-3-540-25979-4_11)
+- [Graph Rewriting Semantics for Functional Programming](https://link.springer.com/chapter/10.1007/3-540-63172-0_35)
+- [Chemlambda Molecular Computing](https://github.com/chemlambda/molecular)
+
+### Term Rewriting Systems
+- [Rewriting Logic and Maude](https://link.springer.com/chapter/10.1007/10721975_1)
+- [Maude: Specification and Programming in Rewriting Logic](https://www.sciencedirect.com/science/article/pii/S0304397501001590)
+- [Maude System (Wikipedia)](https://en.wikipedia.org/wiki/Maude_system)
+- [Maude GitHub Repository](https://github.com/maude-lang/Maude)
+
+### Process Calculi
+- [Process Calculus (Wikipedia)](https://en.wikipedia.org/wiki/Process_calculus)
+- [π-calculus (Wikipedia)](https://en.wikipedia.org/wiki/%CE%A0-calculus)
+- [The Pi Calculus (n-Category Café)](https://golem.ph.utexas.edu/category/2009/08/the_pi_calculus.html)
+
+### Linear Logic
+- [Linear Logic (Stanford Encyclopedia of Philosophy)](https://plato.stanford.edu/entries/logic-linear/)
+- [Introduction to Linear Logic (BRICS)](https://www.brics.dk/LS/96/6/BRICS-LS-96-6.pdf)
+- [Linear Logic (Wikipedia)](https://en.wikipedia.org/wiki/Linear_logic)
+
+### Cellular Automata
+- [Rule 110 (Wikipedia)](https://en.wikipedia.org/wiki/Rule_110)
+- [Wolfram's Principle of Computational Equivalence](https://www.foundalis.com/mat/pce/pce.htm)
+- [Elementary Cellular Automaton (Wikipedia)](https://en.wikipedia.org/wiki/Elementary_cellular_automaton)
+
+### Category Theory and HoTT
+- [Homotopy Type Theory](https://homotopytypetheory.org/)
+- [Homotopy Type Theory (Wikipedia)](https://en.wikipedia.org/wiki/Homotopy_type_theory)
+- [Relationship Between Type Theory and Category Theory (nLab)](https://ncatlab.org/nlab/show/relationship+between+type+theory+and+category+theory)
+- [Higher Category Theory (Wikipedia)](https://en.wikipedia.org/wiki/Higher_category_theory)
+- [Operads in AQFT](https://arxiv.org/abs/2305.03372)
+
+### Wolfram Physics Project
+- [The Concept of the Ruliad](https://writings.stephenwolfram.com/2021/11/the-concept-of-the-ruliad/)
+- [Hypergraph Rewriting (Wolfram Institute)](https://wolframinstitute.org/research/hypergraph-rewriting)
+- [The Case of Hypergraphs](https://www.wolframscience.com/metamathematics/the-case-of-hypergraphs/)
+- [Going Below Axiomatic Mathematics](https://www.wolframscience.com/metamathematics/going-below-axiomatic-mathematics/)
+- [Ruliology: Linking Computation, Observers and Physical Law](https://philsci-archive.pitt.edu/22519/1/Ruliad.pdf)
+
+### Quantum Computation
+- [A Lambda Calculus for Quantum Computation](https://arxiv.org/abs/quant-ph/0307150)
+- [On Quantum Lambda Calculi](https://www.academia.edu/2370968/On_Quantum_Lambda_Calculi_a_Foundational_Perspective)
+- [Two Linearities for Quantum Computing](https://www.sciencedirect.com/science/article/abs/pii/S0303264718301102)
+
+### Linear Types in Practice
+- [Rust and Linear Types](https://medium.com/@martriay/rust-and-linear-types-a-short-guide-4845e9f1bb8f)
+- [The Pain of Linear Types in Rust](https://faultlore.com/blah/linear-rust/)
+- [Automatic Linear Resource Bound Analysis for Rust](https://dl.acm.org/doi/10.1145/3720492)
+- [A Lightweight Formalism for Reference Lifetimes and Borrowing in Rust](https://dl.acm.org/doi/10.1145/3443420)
+
+### AI Code Generation (2025-2026)
+- [State of AI Coding 2025](https://www.greptile.com/state-of-ai-coding-2025)
+- [CodeRAG: Code Retrieval on Bigraph](https://arxiv.org/html/2504.10046v1)
+- [Survey on Code Generation with LLM Agents](https://arxiv.org/html/2508.00083v1)