Asynchronous processing of Coq documents: from the kernel up to the user interface

The work described in this paper improves the reactivity of the Coq system by completely redesigning the way it processes a formal document. By subdividing such work into independent tasks the system can give precedence to the ones of immediate interest for the user and postpones the others. On the user side, a modern interface based on the PIDE middleware aggregates and present in a consistent way the output of the prover. Finally postponed tasks are processed exploiting modern, parallel, hardware to offer better scalability.

💡 Research Summary

The paper addresses the long‑standing reactivity problem of the Coq proof assistant, which becomes especially acute in large‑scale formalizations such as the Odd Order Theorem. Traditional Coq interaction follows a simple REPL model: the user sends commands one by one, the system processes them sequentially, and only after each command finishes does the UI receive a response. This linear execution model forces the prover to compute the entire proof script before any feedback can be shown, leading to delays of hours for massive developments.

To overcome this limitation, the authors redesign the whole processing pipeline from the kernel up to the user interface, introducing three essential ingredients: (1) an asynchronous interaction loop based on the PIDE middleware, (2) a static analysis that partitions the document into coarse‑grained tasks, and (3) a pure‑computation model for those tasks that enables out‑of‑order and parallel execution.

Asynchronous Interaction Loop
Inspired by Isabelle’s PIDE, each command is assigned a unique identifier, and the prover returns reports tagged with the same identifier. The UI therefore sends the entire document to the prover in one batch, while still being able to associate each piece of feedback with the corresponding source fragment. This decouples the UI from the REPL’s strict request‑response discipline and allows the prover to work on any part of the document at any time.

Static Analysis and the State Transaction Machine (STM)
The document is parsed into an abstract syntax tree and each command is classified into one of four categories: global commands, branch‑starting commands (Proof), tactic commands, and branch‑ending commands (Qed). The authors construct a Directed Acyclic Graph (DAG) where nodes represent system states and edges represent atomic transactions (commands). This DAG, managed by the STM, mirrors the way version‑control systems record commits. Global commands are placed on a master branch, while tactics are added to the current proof branch. When a global command appears inside a proof (a common editing practice), the transaction is duplicated: one copy stays on the master branch (preserving its global effect) and another copy lives on the proof branch (treated as a pure computation).

Opaque Proofs and Proof Promises
Coq distinguishes between opaque and transparent proofs. An opaque proof’s term is checked once, stored only as a type, and never used during later checking. Because the term itself is never consulted, the processing of an opaque proof can be deferred without affecting the logical environment. The authors exploit this property by introducing “proof promises”: a promise is a pure computation of the form environment → term. While the proof term is being computed, the theorem is already present in the logical environment as an axiom‑like entry, allowing subsequent parts of the development to proceed.

Implementing pure computations in OCaml, a language with pervasive side effects, is non‑trivial. The solution leverages Coq’s existing Undo facility: a pure computation is packaged together with a snapshot of the system state in which it must run. When the computation is invoked, the current state is saved, the snapshot is restored, the function is executed, and finally the original state is reinstated. This “save‑run‑restore” protocol guarantees that the computation has no observable side effects on the rest of the system.

Parallel Execution
Because tasks (opaque proofs) are independent and modeled as pure computations, they can be scheduled on multiple OS processes or threads. The authors use coarse‑grained concurrency provided by the operating system, avoiding fine‑grained synchronization overhead. The scheduler gives priority to the part of the document the user is currently viewing, while postponing unrelated proofs.

User Interface via PIDE and jEdit
On the front end, the authors integrate Coq’s backend with the PIDE middleware and the jEdit editor. The UI continuously aggregates prover reports and annotates the source text (e.g., red underlines for errors, green highlights for completed proofs). This “spell‑checker” style interaction lets users edit freely while receiving immediate, context‑aware feedback, a drastic improvement over the old “send‑command‑wait‑response” workflow.

Evaluation
Benchmarks on the full proof of the Odd Order Theorem show a ten‑fold improvement in perceived reactivity: after a small edit, feedback is available within seconds rather than hours. When running on a 12‑core machine, the total time to check the entire development drops by a factor of four compared with the sequential version of Coq 8.5. The system also scales well in batch mode, maintaining the speed‑up for large verification tasks.

Related Work and Contributions
The paper acknowledges Isabelle’s earlier work on asynchronous interaction and proof promises, but emphasizes that Coq’s implementation required substantial engineering because of its imperative OCaml codebase and its reliance on a global mutable state. By introducing the STM, DAG representation, and the save‑run‑restore pure‑computation model, the authors provide a concrete pathway to bring modern IDE‑like responsiveness to a traditionally batch‑oriented theorem prover.

Conclusion
Through a comprehensive redesign—introducing an asynchronous PIDE‑based protocol, a DAG‑backed state transaction machine, and a pure‑computation model for opaque proofs—the authors achieve a Coq system that is both highly reactive for interactive use and efficiently parallelizable for batch verification. The work demonstrates that large formal developments can benefit from modern multi‑core hardware without sacrificing the trustworthiness of the proof kernel, and it opens the door for similar enhancements in other interactive theorem provers.