Code that reads like structured English • Quorum's naturalism + Io's minimalism
Repository: Miley-the-dog (named after a very good dog 🐕)
Want to try Moop-like programming right now?
➡️ Trinity Vibe - Related project: Moop semantics in JavaScript syntax. Zero setup, runs in browser immediately.
What's the relationship?
- Moop (this repo): The programming language with natural syntax
- Trinity Vibe: Side project - same concepts (homoiconicity, reversibility), JavaScript syntax
This repo contains the C runtime substrate - the quantum-ready computational foundation for embedded systems and future quantum hardware.
This repo (Miley-the-dog) contains:
- C Runtime Substrate - Quantum-ready computational foundation
- Moop Language Specification - Natural language syntax design
- Examples and Documentation
Related Projects:
- Trinity Vibe - Moop concepts in JavaScript syntax (separate repo, try it now!)
- Quantum-ready backend abstraction (classical/simulator/quantum)
- ~1800 lines of pure C runtime
- 40KB footprint, no garbage collector
- Tape-loop Turing machine with evolutionary pruning
- Perfect for embedded systems and real-time applications
Status: Runtime complete and tested. For language parser/compiler, use Trinity Vibe.
Write clean, natural code:
actor UserManager
role is "handles user authentication and sessions"
state has
logged_in is false
proto DatabaseConnection <- Object
slots: host, port, timeout
No ceremony. No syntactic noise. Just clear computation.
Unified Moop combines natural language elegance with computational power through a 6-sublayer architecture in ~1800 lines of C:
- Quantum-Ready Architecture - Classical by default, quantum-compatible by design
- Natural Language Syntax - Code reads like structured English
- Tape-Loop Turing Machine (1024 circular cells, L1)
- Evolutionary Pruning with Darwinian selection pressure
- Trinary MAYBE (True/False/Unresolved) with LLM confidence
- Self-Modification API (homoiconic code-as-data)
- Actor-Proto Duality (particle-wave duality for coordination)
- Meta-Evolution (the system evolves how it evolves)
Moop uniquely combines homoiconicity (code is data) with reversibility (operations can be undone), creating unprecedented capabilities:
Traditional languages:
- Lisp/Forth: Self-modifying but can't undo ❌
- Quantum computing: Reversible but can't self-modify ❌
Moop:
- ✅ Self-modifying code that can be undone
- ✅ Explore alternative code versions and backtrack
- ✅ Programs that evolve themselves safely
- ✅ Meta-programming with a safety net
# Modify code
operation.gate = SWAP
tape.write(100, operation)
# Test it (reversibly)
result <-> execute_tape(100)
# Don't like it? Rewind!
tape.undo()
This enables: Exploratory programming, self-evolving systems, safe meta-programming, and temporal debugging through code modifications.
Moop is designed following Prigogine's dissipative structures - it's not just a language, it's a living computational system:
Benefits:
- Self-organizing code - Automatically optimizes based on usage patterns
- Emergent stability - Robustness emerges from evolutionary selection
- Adaptive performance - System tunes itself to your workload
- Far-from-equilibrium dynamics - Maintains order through energy flow
# Code evolves itself
# High-fitness operations survive
# Low-fitness operations get pruned
# Performance characteristics adapt to usage
# Manual optimization becomes unnecessary
# The system learns what works
Traditional languages: Static artifacts you manually optimize. Moop: Living organisms that adapt and evolve.
Moop combines gate-based computational substrate with lean conventional memory for an ideal embedded profile:
Dual Memory Architecture:
-
System layer (L1): Gate-based tape-loop
- 1024 circular cells (fixed size)
- Reversible gate operations (CCNOT, CNOT, NOT, SWAP)
- Evolutionary pruning (automatic cleanup)
- No dynamic allocation in computational substrate
-
User layer (L3b): Conventional memory for actor state and proto slots
- Managed by lean C runtime
- No garbage collector
- Predictable allocation patterns
Why Moop excels in embedded environments:
- ✅ Small footprint - ~40KB total runtime (tape + qubit state + runtime)
- ✅ No garbage collector - No unpredictable GC pauses
- ✅ Deterministic behavior - Pruning every 256 ops, O(1) fitness computation
- ✅ Fixed computational memory - 1024-cell tape never grows
- ✅ Lean C implementation - Core runtime ~950 lines, quantum backends ~700 lines
- ✅ Self-managing substrate - Evolutionary pruning handles tape cleanup automatically
actor SensorController
state has
readings is [] # User memory: conventional allocation
last_value is 0
handlers
on process_sensor_data(value)
# Computation happens on L1 gate-based tape
result <-> analyze(value)
# State updates use conventional memory
state.readings.append(result)
state.last_value = result
This makes Moop ideal for:
- Embedded systems (IoT, microcontrollers, sensors)
- Real-time systems (no GC pauses, deterministic timing)
- Resource-constrained environments (fixed computational memory)
- Safety-critical applications (predictable behavior, no hidden allocations)
Comparison:
| Language | Runtime Size | GC Pauses | Deterministic | Computational Memory |
|---|---|---|---|---|
| Python | ~15MB | Yes | No | Heap (unbounded) |
| Java | ~50MB | Yes | No | Heap (unbounded) |
| Go | ~2MB | Yes | No | Heap (unbounded) |
| Rust | ~500KB | No | Yes | Heap (manual) |
| C | Variable | No | Yes* | Heap (malloc) |
| Forth | ~10KB | No | Yes | Stack (fixed) |
| Moop | ~40KB | No | Yes | Tape (1024 cells, self-managing) |
*C is deterministic only if you avoid malloc/free
Key advantage: Moop's computational substrate (L1 tape-loop) is self-managing through evolutionary pruning, while user memory remains simple and predictable.
Moop is designed to run on conventional hardware by default, but with full compatibility for future quantum backends. This is achieved through a clean abstraction layer that separates gate operations from state representation.
Backend Abstraction:
// Same gate API works on any backend
qubit_CNOT(state, control, target); // Classical OR quantum
// Three available backends:
typedef enum {
QUBIT_BACKEND_CLASSICAL, // Default: uint8_t bits (fast, conventional)
QUBIT_BACKEND_SIMULATOR, // Optional: statevector simulation
QUBIT_BACKEND_QUANTUM // Future: real quantum hardware
} Qubit_Backend_Type;Why This Matters:
Moop uses reversible gates (CCNOT, CNOT, NOT, SWAP) as computational primitives. These gates are:
- ✅ Efficient on conventional hardware (simple bit operations)
- ✅ Natively compatible with quantum computers (unitary operations)
- ✅ Mathematically universal (can compute any function)
Key Insight: By building on reversible primitives from day one, Moop programs written today will run on quantum hardware tomorrow without modification.
1. Classical Backend (Default)
// Fast, deterministic, works everywhere
Qubit_State* state = qubit_init(32, QUBIT_BACKEND_CLASSICAL);
qubit_CCNOT(state, 0, 1, 2); // Simple bit operations
uint8_t result = qubit_read(state, 2); // Direct read2. Quantum Simulator (Optional)
// Enable with: make CFLAGS="-DENABLE_QUANTUM_SIMULATOR"
Qubit_State* state = qubit_init(10, QUBIT_BACKEND_SIMULATOR);
qubit_CCNOT(state, 0, 1, 2); // Statevector evolution (2^n amplitudes)
uint8_t result = qubit_measure(state, 2); // Probabilistic collapse3. Quantum Hardware (Future)
// When quantum computers are accessible
Qubit_State* state = qubit_init(100, QUBIT_BACKEND_QUANTUM);
qubit_CCNOT(state, 0, 1, 2); // Runs on real QPU
uint8_t result = qubit_measure(state, 2); // True quantum measurementAll three backends run the same high-level Moop code:
actor QuantumCalculator
role is "performs calculations using quantum-ready gates"
handlers
on compute(a, b)
# These operations work on ANY backend
result <-> CCNOT(a, b, output)
# Classical: fast bit ops
# Quantum simulator: statevector evolution
# Quantum hardware: real superposition
output -> "Result: " + result
Today:
- Run on any conventional computer (x86, ARM, RISC-V, microcontrollers)
- Fast execution using classical bits
- No special hardware required
Tomorrow:
- Same programs run on quantum computers when available
- No code changes needed
- Gradual migration path (classical → simulator → quantum hardware)
Philosophy:
"Write for conventional hardware today. Run on quantum hardware tomorrow."
This makes Moop uniquely positioned for the quantum transition - your investment in Moop code today will pay dividends when quantum computing becomes mainstream.
git clone https://github.com/Blobfish108/Miley-the-dog-.git
cd Miley-the-dog-
make examples
./build/living_code_demoThis demo shows:
- Homoiconicity: Reading and modifying code at runtime
- Reversibility: Time-travel debugging with checkpoints
- Evolution: Self-optimizing fitness-based pruning
- The Synergy: Why this combination is unique
Note: This demo is written in C using the runtime APIs. To write and run actual .moop language files, use Trinity Vibe (see "Try Moop NOW" section above).
makemake testactor Calculator
role is "Performs calculations with evolutionary optimization"
state has
history is []
last_result is 0
handlers
on compute(operation, args)
# Reversible computation
result <-> perform_operation(operation, args)
# Update state (irreversible)
state.last_result = result
state.history.append({op: operation, result: result})
# Output (irreversible)
output -> "Result: " + result
on undo
# Reversibility: can rewind to previous state
if history.length > 0
state.history.pop()
restore_checkpoint(history.length)
on optimize_self
# Meta-evolution: tune fitness parameters
params <- get_fitness_params()
params.recency_weight = 0.6
params.activity_weight = 0.3
tune_fitness(params)
Note: This is Moop language syntax. To run this code, use Trinity Vibe - a self-contained browser implementation with full parser/compiler/IDE. This repo provides the C runtime substrate for embedded systems; Trinity Vibe provides the complete language environment.
L3b: User Actors/Protos ← Application layer
L3a: System Bootstrap ← Actor-proto duality genesis
L2c: User Processing ← (Reserved)
L2b: Irreversible Ops ← AND, OR, XOR, MAYBE resolution
L2a: Reversible Functions ← Non-primitive reversible functions, structural reversibility
L1: Tape-Loop TM ← 1024 circular cells, evolutionary pruning, CCNOT, CNOT, NOT, SWAP
Fitness function with 3 components:
- Recency (50%): Recent operations survive longer
- Qubit Activity (30%): Operations on "hot" qubits prioritized
- Gate Type (20%): Universal gates (CCNOT) favored
Selection pressure: Top 75% survive, bottom 25% discarded every 256 operations
actor AuthService
on authenticate(username, password)
# MAYBE: uncertain value with confidence
maybe user_authenticated is check_credentials(username, password)
when user_authenticated is true:
session <- create_session(username)
output -> "Login successful (confidence: " + user_authenticated.confidence + ")"
when user_authenticated is false:
output -> "Login failed"
otherwise:
# Still uncertain (e.g., awaiting 2FA)
output -> "Awaiting multi-factor authentication"
output -> "Reasoning: " + user_authenticated.reasoning
actor SelfOptimizer
on modify_algorithm
# Read code from tape (homoiconicity)
operation <- tape.read(100)
# Modify it (self-modification)
operation.gate = SWAP
tape.write(100, operation)
# Test the modification (reversibly)
checkpoint <- tape.checkpoint()
result <-> execute_modified_code()
# Don't like it? Rewind!
if result.performance < threshold
tape.restore(checkpoint)
actor EvolutionarySystem
on adapt_to_workload
# System tunes its own evolution (meta-evolution)
params <- get_fitness_params()
# Adjust selection pressure based on usage patterns
params.recency_weight = 0.7 # Favor recent operations more
params.activity_weight = 0.2
params.gate_weight = 0.1
tune_fitness(params)
output -> "System adapted to workload"
The system evolves how it evolves!
- UNIFIED_MOOP.md - Complete specification
- THREE_LAYER_MOOP_ARCHITECTURE.md - Layer architecture
- PRIMITIVE_DUALITY.md - Actor-proto duality
- IMPLEMENTATION_NOTES.md - Enhancement rationale
"Computation is the Modification of Memory"
Moop implements this principle through:
- Homoiconicity: Code is data, data is code
- Reversibility: All R-layer gates are self-inverse
- Tape-Loop: Finite but unbounded circular memory
- Segregated Logic: Reversible (L2a) vs Irreversible (L2b)
- Actor-Proto Duality: Two aspects of one coordination primitive
- C11 compiler (gcc/clang)
- Standard C library
- Make
- libcurl (for LLM integration - currently disabled)
make # Build test suite
make test # Build and run tests
make clean # Remove build artifacts
make help # Show all targets- Tape Size: 1024 operations (L1 constraint)
- Fitness Computation: O(1) per operation
- Pruning Cycle: O(n log n) sort (every 256 ops)
- Memory: ~40KB for tape + qubit state
- Speed: ~1M ops/sec on modern CPU
Comprehensive test suite covering:
- Tape-loop wrapping
- Evolutionary pruning
- Trinary MAYBE resolution
- Self-modification
- Meta-evolution
- Layer segregation
Run with: make test
trinity-vibe - Browser-based exploration of homoiconicity and structural reversibility
Trinity Vibe and Moop share the same philosophical foundations but serve different purposes:
Shared Philosophy:
- Homoiconicity (code as data)
- Structural reversibility (time-travel debugging)
- Three-layer architecture (Functions/Actors/Prototypes)
- Non-Von Neumann computational model
Trinity Vibe's Focus:
- Browser-based (JavaScript, no build step)
- "Memory-as-computation" model
- Interactive exploration and visualization
- Web deployment, rapid prototyping
Moop's Focus:
- Native C implementation (~900 lines)
- Quantum-ready reversible gates
- Embedded systems (40KB footprint, no GC)
- Production deployment, deterministic real-time
Think of them as:
- Trinity Vibe: Web-based laboratory for exploring reversible homoiconic programming
- Moop: Production-ready implementation with quantum compatibility and embedded focus
Both projects explore how reversibility + homoiconicity creates new programming paradigms. Trinity Vibe prioritizes accessibility and experimentation; Moop prioritizes performance and future-proofing.
MIT License - see LICENSE
Pull requests welcome! Please ensure:
- Code passes
make test - New features include tests
- Follows existing code style (K&R, 4-space indent)
Zen Brutalism: No decoration, maximum structural clarity, deep theoretical alignment. Every line earns its place.
The implementation breathes these dualities:
- Actor ↔ Proto (coordination duality)
- Reversible ↔ Irreversible (entropy segregation)
- Code ↔ Data (homoiconicity)
- System ↔ User (a/b sublayer pairs)
The tape is a living, adaptive memory that self-organizes through selection pressure—pure Prigogine dissipative structure at the computational level.
Production-ready alpha - Core features complete, API stable, tests passing.
Generated with evolutionary code that evolves its own evolution 🦎