67 lines
3.9 KiB
Org Mode
67 lines
3.9 KiB
Org Mode
:PROPERTIES:
|
|
:CREATED: [2026-06-03 Tue]
|
|
:ID: a2811c83-b315-47fd-8ab8-25627c389d1a
|
|
:END:
|
|
#+title: CL Modernization — Timeline Estimate
|
|
#+filetags: :HOL:common-lisp:modernization:passepartout:timeline:verification:
|
|
|
|
* Timeline from Now to a Proved Lisp Machine
|
|
|
|
** Phase 0: HOL Kernel in CL (~2-4 months)
|
|
|
|
The smallest, most bounded piece. 500-800 lines of pure CL, well-defined mathematical spec (HOL Light's 10 primitive inference rules). Passepartout writes it, ACL2 verifies it. The first genuine artifact: a verified higher-order prover running inside CL.
|
|
|
|
Dependency: Passepartout can write and debug CL code reliably. Doesn't need much else.
|
|
|
|
Key risk: ACL2 verification of the kernel may require iterations — ACL2's automation is limited and some lemmas may need to be added manually.
|
|
|
|
** Phase 1: Minimal Verified Build System (~4-6 months)
|
|
|
|
A verified build system that can compile CL projects with deterministic lockfiles. Doesn't need to be Cargo-complete — just enough to compile the prover, the LSP, and its own source.
|
|
|
|
Dependency: Phase 0 (prover proves build system correctness). Also a solid understanding of ASDF internals.
|
|
|
|
Key risk: The build system touches the filesystem, subprocesses, and network — all outside the prover's pure core. Only the /dependency resolution and compilation logic/ can be fully proved. The IO layer must be trusted or wrapped in a small verified interface.
|
|
|
|
** Phase 2: Verified LSP Server (~6-8 months)
|
|
|
|
Bridges SBCL's compiler to the LSP protocol. Online mode (connected image) for rich interactivity. Verified to not crash, not deadlock, and produce correct type information.
|
|
|
|
Dependency: Phase 1 (can build and distribute the LSP). Deep SBCL internals knowledge (the agent must learn SBCL's type inference API).
|
|
|
|
Key risk: SBCL's type inference is not designed for an LSP — it's designed for compile-time warnings. Wrapping it in a responsive protocol requires significant engineering.
|
|
|
|
** Phase 3: Coalton + Verified Standard Library (~12-18 months)
|
|
|
|
Coalton as a first-class typed path. Hash sets, priority queues, JSON, HTTP client, async, immutable structures — all proved correct. Unicode-by-default string handling.
|
|
|
|
Dependency: Phase 2 (the agent needs good tooling to develop and debug this volume of code).
|
|
|
|
Key risk: The volume. This is the largest phase by lines of code. The prover has to verify thousands of modules. Verification of complex data structures (hash tables, async schedulers) is non-trivial. This is where proof costs become visible.
|
|
|
|
** Phase 4: Self-Hosting, Self-Verifying CL Stack (~6-12 months)
|
|
|
|
The modernized CL toolchain can compile itself. The compiler is verified. The runtime has a proved GC (at least bounded pause times). Passepartout proves its own transformation rules correct — the self-improving machine.
|
|
|
|
Dependency: Phase 3. The standard library and language must be mature enough to write serious systems software in.
|
|
|
|
Key risk: Self-verification is the hardest problem. Proving that the compiler compiling itself produces a correct binary requires a bootstrapping proof that few systems have attempted. The HOL prover needs to be powerful enough for this.
|
|
|
|
* The Proved Lisp Machine
|
|
|
|
After Phase 4: the agent runs on a proved CL, proving its own transformations as it extends itself. This is the capstone. The machine is no longer gambling on correctness — every change is verified before it applies.
|
|
|
|
* Total Timeline Estimate
|
|
|
|
- Optimistic (smooth sailing): ~2.5-3 years
|
|
- Realistic (normal engineering friction): ~3.5-5 years
|
|
- Conservative (major proof bottlenecks): ~5-7 years
|
|
|
|
The primary uncertainty is Phase 3 (verified standard library volume) and Phase 4 (self-verification bootstrapping). Phase 0 and Phase 1 are relatively predictable.
|
|
|
|
* What Accelerates This
|
|
|
|
- A existing CL community contributing modules to verify
|
|
- An agent that gets faster as it improves its own environment
|
|
- Leveraging existing verified libraries (Coq, Lean, Isabelle) and adapting their proofs rather than proving from scratch
|