TheoremExtr: Hybrid Theorem Extraction Tool

• TheoremExtr is a theorem extraction tool that recovers comprehensive theorem declarations, definitions, and dependencies across Rocq projects.
• It integrates parser-stage extraction of meticulous source-level data with run-time extraction of elaborated types for precise localization.
• The system outputs a JSON database powering a cross-project search interface, facilitating retrieval-augmented proving and corpus construction.

TheoremExtr is a theorem extraction and analysis tool for Rocq that is designed to extract and search theorems, definitions, and their dependencies across projects. It combines parser-stage extraction with run-time extraction and a merging tool, because parser-only extraction can miss imported dependencies and elaborated type information, while run-time extraction alone does not recover source-level structure, scope, file paths, or line numbers precisely enough for source localization. The output is a JSON database that also powers a cross-project search website supporting theorem and definition retrieval, dependency display, associated types, and links back to source locations (Fang et al., 3 Jun 2026).

1. Motivation and problem scope

The motivation for TheoremExtr is the gap between how Rocq users actually reuse formal results and what the native tooling exposes. The paper states that Rocq’s built-in Search command only works over the current run-time environment, so it is restricted to already imported modules and cannot perform cross-project search. At the same time, researchers and tool developers often need structured theorem data for automated theorem proving, retrieval-augmented proving, LLM training for formal methods, theorem corpus construction, and proof dependency analysis. TheoremExtr is presented as addressing both problems simultaneously: comprehensive extraction of theorem-related data and cross-project search over a unified corpus (Fang et al., 3 Jun 2026).

The paper also emphasizes that a theorem is not only a name and a statement. In practice, it depends on functions, inductive types, imported definitions, hidden or implicit arguments, module scopes, and source locations. A single theorem may therefore depend on definitions distributed across multiple files. This motivates an extraction system that can recover theorem composition and the definitions and types it relies on, rather than only surface-level declarations.

2. Hybrid architecture

TheoremExtr has three components: parser-stage data extraction, run-time extraction, and a merging tool. This division is central to the system. Parser-stage extraction captures source-level and location-sensitive information; run-time extraction recovers elaborated theorem types, dependencies, and concrete definition information; the merging tool reconciles both views into complete theorem and definition entries (Fang et al., 3 Jun 2026).

Parser-stage extraction is implemented by modifying parts of the Rocq compiler. The paper says that extraction is integrated into the compiler, retrieves information from data structures representing the abstract syntax tree, and adds auxiliary functions without changing the original compiler logic. At this stage, TheoremExtr extracts theorem statements, definition declarations, names, file names, file paths, module or segment scopes, and line numbers. It identifies theorems by absolute path combined with theorem name, with Coq.Init.Datatypes.nat given as an example of a fully qualified name. Scope handling is explicit: when module-related code begins, the current scope is marked, and theorems defined before module end are treated as internal to that module.

Run-time extraction is implemented as a Rocq plugin exposing the command:

Createdb.

The intended workflow is to import target libraries and then execute Createdb, after which the plugin traverses the currently accessible environment and emits a JSON file. The run-time phase retrieves accessible theorems, analyzes theorem types to recover complete type definitions, traverses theorem subterms, determines whether a subterm corresponds to a function or an inductive type, extracts concrete definitions for inductive types used in theorems, and records theorem absolute paths and names. The paper explicitly notes that some theorem types contain syntactic omission and some arguments are implicit, so this elaborated view is necessary.

3. Extracted artifacts and dependency representation

TheoremExtr extracts several classes of artifacts. For theorems, it aims to recover theorem names, full or absolute theorem paths, statements, source file information, line numbers, enclosing scope or module, dependencies, concrete type-related information, and internal used definitions and inductive types. In addition to theorems, it extracts definition names, declarations, concrete definitions when relevant, and associated types. The paper reports extracting 27,481 definitions and their types (Fang et al., 3 Jun 2026).

Dependency extraction is described operationally rather than axiomatically. The paper does not provide a formal dependency calculus, a formal dependency relation, or inference rules for dependency construction. Instead, dependencies are identified by traversing theorem subterms at run time; if a subterm corresponds to a function or an inductive type, that referenced object is recorded as part of the theorem’s dependency information. For inductive types, the tool also extracts concrete definitions. This suggests a dependency graph whose nodes are theorems, definitions, and inductive types, with edges induced by subterm usage, but the paper does not formalize that graph.

The distinction between statements and types is also explicit. Statements are extracted at parse time as theorem propositions or definition declarations, whereas complete type definitions may require run-time analysis. The distinction between local names and full names is similarly important: parser-stage names may be scope-relative, while run-time names are already full; the merging tool reconstructs parser-stage full names from compilation path, filename, scope, and theorem name.

4. Search, indexing, and cross-project retrieval

The extracted corpus is exposed through a website at https://lemmasearch.com/, while the extraction tool itself is hosted at https://github.com/Rw1nd/TheoremExtr. The search system uses BM25 for similarity search, so retrieval is lexical and ranking-based rather than symbolic proof search. The paper gives the example query store mem, which returns relevant theorems from CompCert. Search results include theorem or definition names, dependencies, associated types, and hyperlinks back to the original repository location (Fang et al., 3 Jun 2026).

Cross-project support is one of the principal claims of the system. The paper contrasts this with Rocq’s built-in Search, which cannot search outside imported modules or across unrelated projects. TheoremExtr addresses this by extracting data from multiple projects into a single searchable corpus. It also contrasts the website with general web search engines, which are described as ineffective for domain-specific Rocq theorem queries.

The paper positions TheoremExtr against several existing workflows. It states that CoqPyt, a Python-based extraction framework relying on coq-lsp, lacks dependency analysis within theorems; that SerAPI can extract internal Coq data but requires learning extra protocol commands; and that coq-lsp requires knowledge of the LSP protocol and is not specific to Rocq. Existing datasets such as CoqGym and CoqStoq are described as useful but either outdated or insufficiently scalable across Rocq versions.

5. Implementation, workflow, and supported corpus

TheoremExtr is implemented on Rocq 8.20.0. The paper identifies version differences as a current limitation and future work target. The user workflow is intentionally simple: compile project files with modified coqc to generate parser-stage JSON, import target libraries in Rocq, execute Createdb to generate run-time JSON, and then merge the outputs with a Python script to obtain the final theorem and definition database (Fang et al., 3 Jun 2026).

The paper reports extraction from 32 open-source projects selected from the Rocq platform version 2025.01.0 and the Rocq community. The listed projects are: coq-aac-tactics, mathcomp-algebra-tactics, mathcomp-analysis, mathcomp-bigenough, coq-bignums, coq-itauto, compcert, coq-corn, coq-equations, coq-ext-lib, coq-fcsl-pcm, coq-gappa, coq-hott, coq-htt, coq-relation-algebra, coq-stdlib, coq-coqeal, coq-coqprime, coq-coquelicot, mathcomp-finmap, coq-flocq, coq-interval, coq-iris, coq-math-classes, mathcomp, coq-mtac2, mathcomp-multinomials, coq-quickchick, mathcomp-real-closed, coq-reglang, coq-stdpp, and coq-vst.

Across these 32 projects, the paper reports extracting 71,795 theorems and their dependencies, together with 27,481 definitions and their types. Experiments were run on Intel Core Ultra 7 265K, 48 GB RAM, Ubuntu 22.04.5 LTS, under Windows Subsystem for Linux. Total extraction time was 6790 seconds, split into 2564 seconds for parser-stage extraction and 4226 seconds for run-time extraction. The run-time phase was often more expensive, with coq-corn taking 1679 seconds and coq-iris 1369 seconds at run time, while large parser-stage costs included coq-vst at 509 seconds and mathcomp-analysis at 447 seconds.

6. Evaluation, limitations, and research uses

The evaluation in the paper is centered on scale, feasibility, extraction throughput, and deployment of the search website, rather than on formal accuracy metrics. The authors do not report precision or recall for dependency extraction, do not provide a manually validated ground-truth benchmark, and do not give a formal coverage rate beyond artifact counts and successful extraction over the 32-project corpus. The paper also does not include a search relevance benchmark or user study (Fang et al., 3 Jun 2026).

Several limitations are explicit or implicit. First, the implementation is version-specific to Rocq 8.20.0, and the authors plan to extend support to future Rocq versions. Second, the notion of dependency remains operational rather than formally specified: the paper does not define exact dependency semantics, transitive closure rules, filtering rules, or treatment of notations, canonical structures, or typeclass resolution in formal detail. Third, run-time extraction can be expensive for large projects. Fourth, TheoremExtr does not alter Rocq’s native search architecture; instead, it compensates externally through extraction and a website-indexed corpus.

The paper identifies several research and tooling uses. Proof engineers can search across projects, inspect dependencies, and locate source definitions. Researchers in automated theorem proving and LLM-based formal reasoning can use the extracted theorem statements, dependencies, definitions, and types to build corpora for retrieval-augmented proving, benchmark construction, and model training. Tool developers can obtain theorem and definition data without protocol-level integration with SerAPI or coq-lsp. The conclusion also states that TheoremExtr can be used in LLM training and within LLM agents, because it provides richer theorem information and more informative feedback. This suggests that TheoremExtr is best understood not only as a search interface, but also as an infrastructure layer for theorem-aware formal-methods tooling.