Papers
Topics
Authors
Recent
Search
2000 character limit reached

Computer Science as Infrastructure: the Spine of the Lean Computer Science Library (CSLib)

Published 16 Feb 2026 in cs.LO and cs.PL | (2602.15078v1)

Abstract: Following in the footsteps of the success of Mathlib - the centralised library of formalised mathematics in Lean - CSLib is a rapidly-growing centralised library of formalised computer science and software. In this paper, we present its founding technical principles, operation, abstractions, and semantic framework. We contribute reusable semantic interfaces (reduction and labelled transition systems), proof automation, CI/testing support for maintaining automation and compatibility with Mathlib, and the first substantial developments of languages and models.

Summary

  • The paper presents CSLib as a centralized infrastructure that formalizes core computer science abstractions using Lean.
  • It details the design of operational semantics and automated proof tactics, achieving significant line-of-code reductions via tools like grind.
  • The integration with Mathlib ensures rigorous maintenance, scalability, and enhanced formal verification across diverse CS domains.

Infrastructure for Formalized Computer Science: The Lean CS Library Spine

Motivation and Foundational Principles

The paper "Computer Science as Infrastructure: the Spine of the Lean Computer Science Library (CSLib)" (2602.15078) advocates for the development of CSLib—a centralized, reusable library formalizing core computer science abstractions in Lean. Inspired by Mathlib’s success in the mathematics domain, CSLib is positioned as a technical backbone supporting formal reasoning and verification across the landscape of computer science. The authors introduce key abstractions, operational semantics, computable definitions, and robust proof automation—all tightly integrated with Mathlib APIs and infrastructure.

The CSLib architecture is motivated by the need for deep formalization of computer science concepts including verified algorithms, programming languages, concurrency models, automata theory, and program equivalences. The goal is not only mechanization but the provision of practical APIs, shared abstractions, and scalable proof automation enabling rigorous, maintainable developments.

Core Abstractions and Semantic Framework

CSLib is architected around shared abstractions serving as canonical interfaces for operational semantics, reduction systems, labelled transition systems (LTSs), contexts, and congruences. Reduction systems and LTSs are formalized as bundled structures, allowing for automatic derivation of multi-step semantics, reachability properties, and classification via finiteness and confluence. The abstract design enables generic reasoning across varied models, including automata and process calculi.

A notable emphasis is placed on computable definitions—contradicting Mathlib’s classical leanings—prioritizing constructions that support executable code extraction. The authors introduce typeclasses (e.g., HasFresh) for generating new elements in infinite types, facilitating automation and bridging classical and computable theories.

Context and congruence abstractions are formalized via canonical typeclasses, enabling the automatic derivation of key properties for language constructs and equivalence relations. The context API supports single-hole contexts and generalizes congruence to equivalence relations preserved across contexts—crucial for operational semantics and reasoning about languages.

Proof Automation and Development Methodology

Automation is designated a first-class concern in CSLib. Interfaces and theorem statements are crafted to maximize the reach of Lean’s proof automation tactics, with routine proof obligations handled by generic, scalable tactics (notably grind). Failures of automation are treated as architectural feedback, driving interface refinements for proof stability and minimization of boilerplate.

Empirical data is presented: of 338 declarations using automation, 314 employed it from inception. Adding grind yields an average reduction of 7.1 LoC per theorem, and proofs involving bisimilarity realize savings between 15–39 LoC. The System F formalization demonstrates a reduction of approximately 45% LoC compared to prior approaches.

As an exemplar, the subset construction converting an NFA into a DFA yields proofs using existing LTS infrastructure and automation, demonstrating seamless compositionality and reuse.

Maintenance, Testing, and Compatibility

CSLib is deliberately constructed atop Mathlib, leveraging its two million lines of formalized mathematics, CI pipeline, linters, and testing infrastructure. Linters are integrated aggressively, adopting strict namespacing and redundancy checks (e.g., mergeWithGrind) for proof tactics. CI is configured to escalate linter warnings to errors, and expensive checks are conducted weekly. Testing includes module-level examples, import graph validation, and annotation analysis to prevent performance degradation.

Kernel-level integrity is maintained via periodic external typechecking on the Lean Kernel Arena platform, satisfying the de Brujin criterion and further mitigating correctness risk.

Enabling Technical Developments

CSLib infrastructure has catalyzed several technical developments, underscoring both its versatility and foundational rigor. Among these, behavioral equivalences (bisimilarity, simulation, trace equivalence) are formalized parametrically over LTS. Bisimilarity is proven strictly finer than trace equivalence, and bisimulations form a join-semilattice under union with bottom/top elements. Bisimulation up-to and sw-bisimulation methodologies are mechanically derived, facilitating efficient reasoning about weak equivalence and simplifying proof games.

The Calculus of Communicating Systems (CCS) is instantiated within CSLib, achieving algebraic laws for process equivalence and commutativity/distributivity of parallel composition. Bisimilarity is proven as a congruence irrespective of constant definitions, demonstrating the generality and flexibility of CSLib’s abstractions.

Lambda-calculi (simply typed and System F) and binding metatheory are formalized leveraging locally nameless variable binding—integrating Mathlib modules and custom metaprograms for notational convenience and aggressive automation. Fresh variable selection is handled via a configurable term elaborator, feeding directly into context inference and further streamlining proof strategies.

Implications and Future Directions

The design and implementation of CSLib constitute a significant step toward universal, verified infrastructure for formalized computer science in Lean. The prioritization of computable definitions and generic abstractions accelerates not just code extraction and verified software synthesis, but also streamlines large-scale mechanization efforts. The integration with Mathlib ensures seamless compatibility, and robust CI/testing fortifies maintainability.

Practical implications include the facilitation of verified programming language tools, scalable concurrent model checking, and mechanized algorithm benchmarks with explicit complexity bounds. The deep abstraction boundary and automation-centric methodology create prospects for integrating advanced logics (e.g., nominal transition systems, π\pi-calculus), database theory, distributed systems, and even AI model verification.

Theoretical implications encompass the propagation of formal verification standards and compositional reasoning into domains previously isolated from mainstream mechanization, potentially informing future developments in program synthesis, specification checking, and secure distributed computation.

Conclusion

CSLib emerges as a technical backbone for formalizing computer science concepts in Lean, overlaying shared abstractions, computable APIs, and pervasive proof automation atop Mathlib. The empirical evidence for automation efficacy and rigorous maintenance establishes CSLib as a scalable, sustainable platform for verified software, programming languages, and foundational theory. The methodology and infrastructure lay a foundation for continued expansion into diverse domains within computer science, with broad implications for both practical verification and foundational theory.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

What is this paper about?

This paper introduces CSLib, a shared “toolbox” for computer science inside Lean, a popular computer system that checks math and code proofs. Think of CSLib as roads, bridges, and power lines for formal computer science: it gives people the common parts they need to build and verify programming languages, algorithms, and system models so that a computer can check they are correct.

What questions are the authors trying to answer?

The paper focuses on simple, practical questions:

  • How can we give computer scientists a common set of building blocks to describe how programs run, compare programs, and prove properties about them?
  • How can we make writing and checking these proofs faster and less repetitive?
  • How can we keep this big library consistent, fast, and easy to update as it grows and as Lean’s main math library (Mathlib) changes?
  • Can we show these tools really work by building standard examples from computer science on top of them?

How do they approach it?

The authors design CSLib around reusable, easy-to-combine parts, and lots of automation. Here are the key ideas, with everyday analogies:

  • Operational semantics: Rules for how programs “move” step by step
    • Like the rules of a board game: from one position, what moves are allowed?
    • They provide two standard “game boards”:
    • Reduction systems: unlabelled one-step moves.
    • Labelled transition systems (LTS): moves that carry a label (like roads on a map with names), so you know not just that you moved, but how you moved.
  • Computable definitions: Prefer definitions that a computer can actually run
    • Instead of saying “this set is infinite” in a very abstract way, CSLib gives a “fresh” function that can always pick a new element not used before—like finding a new username that’s not taken.
  • Contexts and congruences: Reasoning that fits inside bigger programs
    • A context is a term with a hole (like a Lego frame where you can plug in a piece).
    • A congruence is an “equivalence that survives context”—if two pieces are equivalent, then building the same structure around either piece still gives equivalent results.
  • Proof automation as a first-class feature:
    • They shape definitions so that a small number of “robot helpers” (tactics) can finish many proofs automatically, especially a tactic called “grind” that stitches routine steps together.
  • Reliable engineering:
    • Continuous integration (CI): automatic checks run every time someone changes the library, like a safety test bench.
    • Linters: style and correctness “spellcheckers” for code.
    • Tests: both fast checks and weekly heavy checks to keep performance and quality stable.
    • Compatibility with Mathlib: reuse a huge base of math theorems and tools.

To prove it all works, they build well-known computer science examples on top of CSLib: automata (machines that read strings), concurrency models (like CCS), and lambda calculi (simple languages used to study programming).

What did they find or build?

The paper reports concrete, reusable results that make formal computer science faster and sturdier:

  • Shared, plug-and-play semantics interfaces:
    • Ready-made structures for reduction systems and LTSs, with standard notions like “reachable states,” “many-step moves,” and classifications (e.g., confluent systems).
  • Computable “freshness” for infinite types:
    • A HasFresh interface that provides fresh elements on demand, helping build executable definitions and proofs that avoid tricky non-executable parts.
  • Contexts and congruences:
    • A general setup to define “fill a hole with a term” and to declare when an equivalence still holds after you plug terms into bigger programs.
  • Automation that actually saves work:
    • Proofs using equivalences like bisimilarity (a standard way to say two processes behave the same) are much shorter and more maintainable with automation.
    • Example: converting an NFA (a nondeterministic automaton) to a DFA (deterministic) and showing they recognize the same language becomes a tiny proof, because CSLib already knows the right facts about transitions and images.
  • Major reference developments on top:
    • Behavioral equivalences (bisimilarity, similarity, trace equivalence) with clean theorems about how they relate, and lattice structure for bisimulations (you can union them and still keep good properties).
    • CCS (Calculus of Communicating Systems): a classic model of concurrent processes with laws like “parallel composition is commutative,” and the big result that bisimilarity is a congruence (it survives plugging into any context).
    • Lambda calculi (including System F with subtyping): foundational languages formalized using “locally nameless” variables for simpler, reliable handling of bound variables. They even provide a “fresh variable” elaborator that automatically gathers free variables and picks a fresh one in a user-friendly way.

Why is this important? Because these components are:

  • Generic: they work across many topics, so you don’t start from scratch.
  • Executable when possible: more definitions run as actual programs, not just paper math.
  • Automated: routine proof steps are handled by the system, saving human effort.
  • Already used: they’ve enabled new formalisms (like automata theory and logics) and are feeding into projects that verify real software.

What does this mean for the future?

CSLib is an infrastructure bet: if you build strong, shared foundations, you make it much easier to:

  • Verify new and existing programming languages and systems with machine-checked proofs.
  • Develop and compare algorithms (including with time bounds) with fewer errors.
  • Teach and reuse standard CS theory in a living, executable form.
  • Scale community effort: better automation and CI mean more stable growth and less repeated work.

In short, CSLib aims to do for computer science what Mathlib did for mathematics in Lean: provide a common, well-designed base so researchers, engineers, and students can build correct-by-construction results faster, with fewer bugs, and with strong guarantees the computer can check.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a single, actionable list of what remains missing, uncertain, or unexplored in the paper, targeting concrete directions for future work.

  • Coverage of semantic styles: no APIs for big-step (natural) semantics, denotational semantics, or categorical/coalgebraic semantics, nor equivalence theorems linking them to the provided small-step/LTS frameworks.
  • Effectful semantics beyond LTS: no unified infrastructure for probabilistic, nondeterministic, stateful, exception, I/O, real-time, or hybrid-system semantics (e.g., generic monadic semantics adapters, time constraints, or measurable LTSs).
  • Weak transitions and τ-actions: while weak bisimilarity is provided, there is no library-level, reusable API for τ-closure construction, properties (e.g., saturation), and automation of weak-transition reasoning across arbitrary LTS instances.
  • Model-checking and decision procedures: absence of generic algorithms and interfaces for bisimulation/simulation checking, language inclusion, and model checking (including complexity guarantees and correctness proofs).
  • Nominal/π-calculus infrastructure: the planned logics for nominal transition systems and a full formalization of the π-calculus (with name binding in transitions) are not yet present; missing are nominal sets, freshness/α-equivalence APIs, and proofs of congruence results in that setting.
  • Contexts and congruence generality: the current single-hole HasContext does not cover multi-hole contexts, evaluation contexts, negative positions, or effectful contexts; generalization and corresponding congruence notions are left open.
  • Freshness and name generation: the HasFresh class lacks a systematic account of prerequisites (e.g., DecidableEq, finiteness assumptions), guarantees (e.g., minimality, stability under substitution), and compositionality for nested binders and multi-sorted languages.
  • Bridging computable/noncomputable: guidelines and metatheorems are missing for when to use computable vs classical (noncomputable) definitions, and for ensuring that proofs using classical bridges still yield executable artifacts with predictable performance.
  • Reusability across multi-sorted and mutual inductive languages: no generic infrastructure for multi-sorted terms, mutual inductive syntax, or vector substitutions comparable to Autosubst-style frameworks, and no migration path from locally nameless to alternative binding representations.
  • Automation performance and stability: no quantitative evaluation of the grind tactic (runtime, success rate, determinism), regression benchmarks, or guarantees of proof stability across Lean/Mathlib upgrades; missing are profiling tools, timeout policies, and reproducibility kits.
  • Automation transparency and control: lacking documentation and tooling to inspect the rule databases used by grind, prioritize/disable rules, debug failures, or localize automation scope to prevent lemma pollution across modules.
  • LTS scalability: no analysis of scalability for large or infinite-state systems (e.g., image-finiteness checks, on-demand generation of reachable states, caching/memoization strategies) or APIs to control exploration breadth/depth in proofs.
  • Confluence/termination toolchain: although properties like confluence/diamond are named, there is no generic automation (e.g., completion, termination orders) or reusable pipeline to prove these properties for new reduction systems.
  • CCS coverage: the CCS development does not demonstrate decision procedures, completeness of algebraic laws, or treatment of advanced operators (e.g., restriction/relabelling variations, recursion/replication) with performance-aware automation.
  • Lambda-calculus metatheory depth: beyond typing and contexts, there is no generic framework for logical relations, normalization, type soundness progress/preservation theorems packaged as reusable APIs, or verified interpreters/compilers for these calculi.
  • Import graph and layering policy: while an import-graph check exists, there is no formally specified layering/architecture policy (e.g., forbidden dependencies, cycles, or abstraction boundaries) with enforceable rules and CI checks.
  • CI and linting metrics: missing are build-time and linter-time budgets, trend tracking, and automatic detection of performance regressions/flaky proofs; weekly heavy lints lack thresholds/SLAs and actionable reporting for contributors.
  • Mathlib dependency management: no stated deprecation strategy, semantic versioning, or compatibility layer for breaking changes in Mathlib/Lean, nor tooling to batch-update cslib when upstream APIs evolve.
  • External kernel checking coverage: kernel arena checks are mentioned but not characterized (coverage, frequency, cross-checker diversity); there’s no public dashboard tying specific commits to external checker outcomes.
  • Executable artifacts and code generation: the execution behavior and efficiency of compiled Lean code for computable definitions are not evaluated; no guidance on ensuring that verified definitions compile to performant code or on bridging to external runtimes (e.g., Rust/C).
  • Interoperability with other provers/tools: there is no import/export or translation layer to Coq/Isabelle/Agda, nor connectors to external model checkers, SMT solvers, or verification backends beyond Lean’s kernel.
  • Benchmarks and case studies: LoC savings are reported anecdotally; there is no standardized benchmark suite (diverse languages/models), no end-to-end case studies (e.g., verified compiler pipeline), and no comparisons with analogous frameworks in other provers.
  • Usability and contributor experience: missing are prescriptive style guides for automation-friendly theorem statements, “skeleton proof” workflows, tutorial tracks, and patterns to avoid brittle proofs; no user studies measure onboarding time or productivity.
  • API specification and stability: the paper outlines principles but not formalized API contracts (pre/postconditions, invariants, expected automation support), nor a process to assess breaking changes against those contracts.
  • Property-based testing for computable parts: beyond proof-level guarantees, there is no property-based/randomized testing harness to sanity-check executable definitions, especially where classical bridges might hide corner cases.
  • Verified algorithms and complexity: while algorithms with time bounds are mentioned externally, there is no unified complexity framework integrated with cslib semantics (e.g., cost semantics, Big-O APIs, resource-aware interpreters) and no case studies connecting proofs to runnable implementations.
  • Documentation of weak bisim up-to methods: conditions ensuring soundness/completeness and reusability across LTS variants are not fully systematized (e.g., monotonicity, compatibility conditions), limiting safe application in new models.
  • Industrial-scale maintenance risks: as automation footprints grow, there is no plan for curating the grind lemma database (e.g., pruning, namespacing, tagging), nor metrics to prevent blow-ups (beyond a single threshold-based test).
View Paper Prompt  View All Prompts 

Practical Applications

Immediate Applications

The points below summarize deployable use cases that can be implemented with the current Lean 4 and Mathlib-compatible version of cslib, leveraging the provided abstractions (ReductionSystem, LTS), proof automation, CI/testing, and language metatheory components.

  • Verified state-machine and automata workflows for software components
    • Sector: software, embedded systems, robotics
    • Use case: Model device controllers, parsers, and protocol handlers as LTS/NFA; determinize and prove language equivalence (e.g., NFA→DFA) using cslib’s LTS.setImage and automation.
    • Tools/products/workflows: “Lean+cslib modeling template” for finite-state systems; CI jobs that check automata equivalence for regressions; unit-test-style proofs alongside code.
    • Assumptions/dependencies: Lean 4.28.0-rc1, cslib/Mathlib availability; engineers comfortable modeling behavior as LTS; performance of grind automation sufficient for target systems.
  • Concurrency protocol equivalence checking via bisimilarity and CCS
    • Sector: distributed systems, telecom, cloud infrastructure
    • Use case: Formalize concurrent components (e.g., semaphores, message-passing) in CCS and prove refactorings preserve behavior using bisimulation/weak bisimulation and up-to methods.
    • Tools/products/workflows: “CCS-based protocol equivalence checker” embedded in Lean; proof-backed code reviews for concurrency changes; regression proofs for protocol updates.
    • Assumptions/dependencies: Protocol expressible in CCS/LTS; appropriate action labels; access to cslib bisimulation libraries and congruence instances; adoption of Lean in engineering teams.
  • Rapid prototyping of verified DSLs and language semantics
    • Sector: compilers, developer tooling
    • Use case: Define operational semantics, contexts, and congruences for new DSLs; prove type preservation, progress, confluence using ReductionSystem/LTS abstractions and canonical HasContext/Congruence typeclasses.
    • Tools/products/workflows: “Lean DSL skeleton” templates; reusable notation for single/multi-step reductions; pipelines for proofs of safety and equivalence as part of language releases.
    • Assumptions/dependencies: Mathlib and cslib available; developers can map language constructs to cslib APIs; automation-friendly statement design (to benefit from grind).
  • Proof automation for routine obligations in formal developments
    • Sector: R&D, academia, open-source verification
    • Use case: Reduce boilerplate across proofs of equivalences, reachability, and invariants using grind and curated lemma databases; enforce quality via linters (e.g., mergeWithGrind).
    • Tools/products/workflows: Shared tactic configurations per project; weekly linter reports to prune redundant steps; standardized lemma naming/structure to maximize automation.
    • Assumptions/dependencies: Project statements aligned to automation patterns; maintainers adopt linter schedules; stable CI integration.
  • CI/testing and quality governance for Lean-based projects
    • Sector: DevOps for formal methods, open-source library stewardship
    • Use case: Reuse cslib’s CI setup: syntax and environment linters, import-graph checks, weekly heavy linters, and Lean Kernel Arena cross-checking.
    • Tools/products/workflows: “cslib-style CI starter” for Lean projects; dashboards reporting tactic redundancy, namespace hygiene, and kernel replay check outcomes.
    • Assumptions/dependencies: GitHub/CI infrastructure; willingness to enforce stricter namespacing; periodic heavy-linter costs accepted.
  • Course modules and exercises for formal CS education
    • Sector: higher education (CS theory, PL, verification)
    • Use case: Teaching operational semantics, automata theory, and concurrency via executable proofs; student assignments verifying NFA/DFA equivalence, bisimulation laws, and type soundness.
    • Tools/products/workflows: Public cslib repository with examples; assignment repositories with CI that lint and check proofs; lecture demos using CCS and lambda calculi formalizations.
    • Assumptions/dependencies: Students have Lean toolchains; instructors adopt cslib abstractions; course time allocated to proof assistant onboarding.
  • Reproducible research packages in PL/concurrency/formal semantics
    • Sector: academia
    • Use case: Publish papers with accompanying Lean/cslib mechanizations and CI; export kernel declarations for independent replay; reuse cslib abstractions to shorten development time.
    • Tools/products/workflows: Artifact evaluation workflows with CI and Lean Kernel Arena verification; standardized cslib-based “research skeletons.”
    • Assumptions/dependencies: Journal/conference support for mechanized artifacts; alignment with cslib versions; authors incorporate computable definitions where feasible.

Long-Term Applications

The points below require further scaling, wider adoption, or extensions (e.g., larger models, integrated code generation, domain-specific instantiations), aligning with cslib’s roadmap toward universal formalization, verified algorithms, and language verification infrastructure.

  • End-to-end verified language toolchains (compilers, interpreters, optimizers)
    • Sector: software tools, safety-critical systems
    • Use case: Build fully verified compilers for DSLs using cslib’s operational semantics, congruence properties, and binding metatheory; prove optimization correctness via bisimulation/simulation.
    • Tools/products/workflows: “cslib-based compiler verification suite”; proof-backed optimization passes; automated regression proofs upon compiler changes.
    • Assumptions/dependencies: Mature coverage of language features (effects, concurrency, exceptions); bridges to code generation; scaling of automation to large codebases; team expertise in Lean.
  • Scalable model checking and verification platforms on top of LTS/bisimilarity
    • Sector: cloud infrastructure, telecom, robotics
    • Use case: Industrial-strength model checking of microservices, service meshes, and controllers; compositional proofs of behavioral equivalence and safety.
    • Tools/products/workflows: Lean-integrated model-checker with cslib semantics; adapters from system specs (e.g., YAML, protocol DSLs) into LTS; proof-carrying deployment gates.
    • Assumptions/dependencies: Performance improvements for large models; domain-specific label types and abstractions; integration with operational telemetry or formal specs.
  • Verified concurrent and distributed systems (consensus, fault tolerance)
    • Sector: cloud, finance, blockchain, edge computing
    • Use case: Formalize and verify protocols like Raft/Paxos and smart-contract execution semantics; prove liveness/safety and equivalence across refactorings.
    • Tools/products/workflows: “cslib consensus verification pack”; libraries of reusable lemmas; certification artifacts for audits and compliance.
    • Assumptions/dependencies: Expressive logics for name-binding and mobility (e.g., pi-calculus extensions); adequate support for probabilistic or timing behaviors; regulator recognition of formal proofs.
  • Certified algorithm libraries with time-complexity bounds and correctness proofs
    • Sector: finance, healthcare analytics, AI/ML infrastructure
    • Use case: Deliver provably correct and complexity-bounded algorithms for scheduling, risk analysis, and data processing; swap-in verified routines for critical pipelines.
    • Tools/products/workflows: “CertifiAlgo” cslib-based catalog; CI that rejects algorithm updates lacking proofs; integration with production via wrappers.
    • Assumptions/dependencies: Breadth of algorithms formalized; performance parity with non-verified counterparts; organization willingness to adopt proof-backed code.
  • Verified privacy, security, and authorization languages
    • Sector: security, cloud services, regulated industries
    • Use case: Use cslib abstractions to model and verify privacy-preserving transformations, policy languages, and access-control systems; guarantee non-interference and compliance properties.
    • Tools/products/workflows: “cslib policy verification toolkit”; compositional proofs of policy refactoring invariants; verified samplers and randomness interfaces where needed.
    • Assumptions/dependencies: Extended probability/measure-theory support; integration with production runtimes; compatibility with existing policy engines and data systems.
  • Formal verification for safety certification pipelines
    • Sector: aerospace (DO-178C), automotive (ISO 26262), medical devices (IEC 62304)
    • Use case: Embed cslib-driven proofs in certification artifacts for software components; prove adherence to safety properties and behavioral equivalences under updates.
    • Tools/products/workflows: “Proof-backed safety certification CI”; auditors run kernel replay checks; traceable link from requirements to mechanized proofs.
    • Assumptions/dependencies: Standards bodies’ acceptance of Lean-based artifacts; training and tooling for auditors; sustained maintenance of proofs across product lifecycle.
  • Education at scale: interactive, proof-driven curricula
    • Sector: education
    • Use case: University and professional training using cslib-based labs for semantics, concurrency, and PL metatheory; students learn to design automation-friendly proofs.
    • Tools/products/workflows: MOOC modules with cslib artifacts; automated graders running linters and grind; repositories of reusable exercises.
    • Assumptions/dependencies: Broader Lean adoption; improved onboarding materials; institutional investment in formal methods pedagogy.
  • Cross-system interoperability and multi-checker verification
    • Sector: formal methods tooling ecosystem
    • Use case: Export Lean kernel declarations and replay in independent checkers; port cslib abstractions to bridge with other provers/languages for redundancy.
    • Tools/products/workflows: “Kernel replay pipelines” in CI; adapters to Coq/Isabelle ecosystems; duplication of key proofs across checkers.
    • Assumptions/dependencies: Stable export formats; consensus on cross-verification standards; resource allocation for dual maintenance.

These applications leverage cslib’s core innovations—shared operational semantics interfaces, context/congruence typeclasses, computable definitions, first-class automation, and robust CI/linters—to shorten time-to-proof, raise proof quality, and enable reusable verification infrastructure across sectors.

View Paper Prompt  View All Prompts 

Glossary

  • Abstract reduction systems: A framework where computation steps are modeled as a binary relation over terms. "Two influential approaches to operational semantics are abstract reduction systems and labelled transition systems (LTSs)."
  • Bisimilarity: An equivalence relation relating states that can mutually simulate each other’s transitions (possibly with internal steps). "We provide bisimilarity, weak bisimilarity, simulation equivalence, similarity, and trace equivalence."
  • Bisimulation: A relation witnessing step-by-step behavioral equivalence between states of an LTS. "An important result is that the union of two bisimulations is a bisimulation."
  • Bisimulation up-to method: A proof technique that allows simplifying bisimulation proofs by using a coarser relation or known equivalences. "the bisimulation up-to method, which allows for stopping the bisimulation game as soon as two bisimilar states are reached"
  • Calculus of Communicating Systems (CCS): A process calculus for modeling and reasoning about concurrent systems and communication. "We formalise Milner's CCS"
  • Concurrency theory: The study of systems with multiple interacting computations occurring simultaneously. "the Calculus of Communication Systems (a reference example for concurrency theory)"
  • Confluence: The property that different reduction paths from the same term can be joined to a common result. "such as finiteness, image-finiteness, confluence, the diamond property, etc."
  • Congruence: An equivalence relation preserved by all language constructors or contexts. "bisimilarity is a congruence for CCS"
  • Continuous Integration (CI): An automated pipeline for building, testing, and maintaining software compatibility and quality. "A Continuous Integration (CI) pipeline to help with maintenance and handle alignment with Mathlib"
  • CovariantClass: A Mathlib typeclass capturing covariance (monotonicity) of an operation with respect to a relation. "covariant (using CovariantClass from Mathlib) with the fill operation."
  • de Brujin criterion: A trust principle that ensures proofs are checked by a small, reliable kernel. "Lean use a small trusted kernel satisfying the de Brujin criterion"
  • DFA (deterministic finite-state automaton): A finite automaton with deterministic transitions for each input symbol. "translate an NFA (nondeterministic finite-state automaton) into a DFA (deterministic finite-state automaton)"
  • Diamond property: The property that two single-step reductions from the same term can be joined in one step to a common successor. "such as finiteness, image-finiteness, confluence, the diamond property, etc."
  • Hennessy–Milner Logic: A modal logic used to reason about labeled transition systems and process behaviors. "including new formalisations of automata theory, Hennessy--Milner Logic, combinatory logic, linear logic, algorithms with time complexity bounds, and more."
  • Hygienic macros: Macro systems that preserve lexical scoping and avoid variable capture. "Lean 4 is self-hosted and provides a rich system of metaprogramming and hygienic macros"
  • Image-finiteness: A property where, for each state and label, the set of successor states is finite. "such as finiteness, image-finiteness, confluence, the diamond property, etc."
  • Join-semilattice: An ordered algebraic structure where any two elements have a least upper bound (join). "bisimulations and union form a join-semilattice with bottom and top elements"
  • Labelled transition systems (LTSs): State-transition models where transitions are annotated with labels. "Two influential approaches to operational semantics are abstract reduction systems and labelled transition systems (LTSs)."
  • Lambda calculus (λ\lambda-calculi): Formal systems for function abstraction and application foundational to programming language theory. "the metatheory of λ\lambda-calculi, currently including the simply typed λ\lambda-calculus and System F with subtyping."
  • Linters: Static analysis tools that check code for style and correctness issues. "This supported the growth of a rich ecosystem of linters"
  • Locally nameless variable binding: A representation using de Bruijn indices for bound variables and names for free variables to simplify proofs. "our use of locally nameless variable binding in conjunction with proof automation and metaprogramming is novel."
  • Mathlib: The centralized Lean library of formalized mathematics. "Mathlib -- the centralised library of formalised mathematics in Lean"
  • Metaprogramming: Writing programs that manipulate or generate code or proofs. "Lean 4 is self-hosted and provides a rich system of metaprogramming and hygienic macros"
  • NFA (nondeterministic finite-state automaton): A finite automaton that can have multiple possible transitions for a given state and input. "translate an NFA (nondeterministic finite-state automaton) into a DFA (deterministic finite-state automaton)"
  • Nominal transition systems: Transition systems where actions may bind names in successor states. "Inspired by formalisations of nominal transition systems"
  • Operational semantics: The description of program behavior via step-wise execution rules (relations). "Two influential approaches to operational semantics are abstract reduction systems and labelled transition systems (LTSs)."
  • Process calculus: Formal models for concurrent processes and their interactions. "cslib's first process calculus"
  • Simulation equivalence: An equivalence notion where systems can mutually simulate each other’s behavior. "We provide bisimilarity, weak bisimilarity, simulation equivalence, similarity, and trace equivalence."
  • SMT solvers: Automated reasoning tools for satisfiability modulo theories. "a tactic inspired by SMT solvers"
  • Subset construction: The algorithm for converting an NFA into an equivalent DFA by using sets of NFA states as DFA states. "Consider the standard subset construction to translate an NFA (nondeterministic finite-state automaton) into a DFA (deterministic finite-state automaton)"
  • Subtyping: A type system relation where one type is a subtype of another, allowing substitutability. "System F with subtyping."
  • sw-bisimulation method: A technique that simplifies the weak bisimulation game by constraining the initial challenge. "and the sw-bisimulation method, which simplifies the weak bisimulation game so that the initial challenge is a single transition."
  • System F: The polymorphic lambda calculus with universal quantification over types. "our System F formalization"
  • Term elaborator: A front-end mechanism that expands user syntax into core terms. "Instead of a tactic we define a term elaborator, a metaprogram that expands user syntax into a term."
  • Trace equivalence: Equivalence based on having the same set of observable execution traces. "We provide bisimilarity, weak bisimilarity, simulation equivalence, similarity, and trace equivalence."
  • Typeclass inference: Automatic resolution of typeclass instances by the compiler or proof assistant. "compatibility with typeclass inference (in particular HasFresh) and proof automation."
  • Typeclasses: Interfaces capturing shared operations/properties discoverable via inference. "typeclasses to classify systems according to different criteria"
  • Weak bisimilarity: Bisimilarity that abstracts away internal (silent) transitions. "We provide bisimilarity, weak bisimilarity, simulation equivalence, similarity, and trace equivalence."
  • π-calculus: A process calculus for mobile processes with name passing and binding. "as in the π\pi-calculus"
View Paper Prompt  View All Prompts 

Open Problems

We found no open problems mentioned in this paper.

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 6 tweets with 121 likes about this paper.

Sign Up for Free