LeanSSR: Lean 4 Small Scale Reflection
- LeanSSR is an implementation of the Small Scale Reflection methodology in Lean 4, enabling concise and maintainable proof scripts.
- It integrates logical and Boolean frameworks seamlessly using implicit reflection and advanced metaprogramming features.
- LeanSSR reduces boilerplate and enhances readability in porting mathematical proofs, demonstrating significant improvements over traditional SSReflect.
LeanSSR is the implementation of the Small Scale Reflection (SSR) proof methodology and tactic language for the Lean 4 proof assistant, directly inspired by Coq’s SSReflect system. LeanSSR delivers concise proof scripting, powerful rewriting/simplification, and effective hypothesis management while leveraging Lean 4’s metaprogramming infrastructure. Its design emphasizes seamless integration between logical (Prop-valued) statements and their Boolean counterparts, yielding shorter, clearer, and more maintainable proof scripts without requiring explicit representation switching. Proof engineers benefit from maintainability, interoperability with Lean’s mathlib4 and ported Mathematical Components libraries, and the ability to extend tactic behaviors in Lean 4’s native language (Gladshtein et al., 2024).
1. Principles and Language Architecture
LeanSSR adheres to three core principles:
- Chained Tactic Language: LeanSSR scripts operate with a concise, tactic-chaining language where each proof step can manipulate both the goal’s quantifier stack and the local hypothesis context. The principal entry point is the
move=>construct, which combines the effects ofrevert,intro, andsimp, with support for flexible intro patterns (?,*,/[swap],/[dup], and alternations such as![ … | … ]). - Unified Rewriting and Simplification: The
srw(ssreflect-rw) tactic interleaves rewriting (rw), direction toggling, focused occurrence selection (e.g.,-[2]for right-to-left rewrite at the 2nd occurrence), and calls to simplification tactics (simp,dsimp), supporting rewriting both in goals and in hypotheses specified viaat H. - Implicit Reflection: The reflection discipline enables implicit conversion between Prop-valued predicates and Boolean-valued functions. Unlike SSReflect in Coq, no explicit tactics are needed to switch between logical and symbolic representations (e.g., no manual
apply ↔P2b).
Under the hood, LeanSSR is implemented entirely within Lean 4, utilizing its metaprogramming API. Key mechanisms include:
| Aspect | Role in LeanSSR | Notable Implementation |
|---|---|---|
| Syntax Categories | Structure tactic language grammar | declare_syntax_cat |
| Macro Rules | Expand composite tactic patterns | macro_rules |
| Elaboration Rules | Specify tactic execution semantics | elab_rules |
| Custom Env Extensions | Propagate rewrite locations (e.g., at H) |
EnvExtension |
evalTactic |
Single-point script evaluation and tracing | - |
Everything is open to user extension via new rules, with no core recompilation required (Gladshtein et al., 2024).
2. Formal Definitions and Key Lemmas
Central to LeanSSR is the Reflect class:
1 2 3 |
class inductive Reflect (P : Prop) : Bool → Type | T (h : P) : Reflect P true | F (h : ¬P) : Reflect P false |
The #reflect command automates the generation of canonical lemmas linking Boolean functions with their logical specifications. For example, #reflect even evenb produces:
toPropEq:
Hypotheses manipulation and targeted rewriting are enabled by tactics such as:
1 |
by move=> ?; srw -[2] (IH m') // |
-[2] targets the second occurrence in right-to-left rewriting using an inductive hypothesis.
3. Metaprogramming Infrastructure
LeanSSR exploits three Lean 4 metaprogramming features:
- Syntax Categories, Macro and Elaboration Rules: Tactic languages are defined via custom syntax categories (e.g.,
ssrTriv). Macros expand complex patterns, and elaboration rules execute Lean tactics. For example, composite scripts like//==are expanded to/== //via macros, and tokens such as//=,/==are interpreted into Lean’s standard tactics.evalTacticmanages parsing, expansion, and execution, providing before/after state tracking for editor tooling and diagnostics. - Custom Environment Extensions: When tactics must operate at specific locations (hypothesis, goal), custom environment entries (
locExt) are employed to track locations across macro expansions and tactic executions. - Type-Class–Driven Reflection: Reflect instances, tagged with
@[reflect], enable Lean’s type-class inference to supply reflection proofs automatically. This unifies decidability and rewriting—whenever can be inferred,Decidable Pis also available, and symbolic and logical forms can be rewritten interchangeably.
Since these features are implemented with Lean’s user-level APIs, proof engineers can extend the tactic suite, add intro patterns, or insert new rewrite rules without modifying Lean’s kernel or externalizing plugins.
4. Applications: Case Studies
4.1 Porting Mathematical Components Sequence Lemmas
Approximately 10% of the Coq Mathematical Components seq.v file (including 31 definitions and 72 theorems) was ported nearly mechanically with LeanSSR. For example, subsequence transitivity (subseq_trans) shrank from a 12-line, rewrite-heavy SSReflect/Coq proof requiring explicit predicate switches, to a 9-line LeanSSR proof with no explicit application of reflect predicates or rewrite calls. The //= tactic absorbs all rewrite and simplification steps, removing boilerplate.
4.2 Finite Set Lemma Refactoring in mathlib4
In mathlib4, proofs concerning cardinalities of images under bijections typically required explicit pattern matching, constructors, and manual manipulation. The LeanSSR adaptation reduced a 6-line subgoal proof (involving fun, rintro, explicit instance use) to a 4-line script with a single move=>, alternation via ![ … | … ], and four view patterns, bringing the script closer to standard mathematical argumentation and reducing line count by approximately one third.
5. Comparison with SSReflect and Practical Impact
LeanSSR’s main advantages over SSReflect for Coq include:
- Implicit Prop/Bool Reflection: Tactics and simplification steps automatically handle transitions between logical and Boolean predicates (no need for explicit
apply/ReflectP), streamlining proof scripts. - Editor Usability: Hooks in
evalTacticallow for precise proof state visualization and token-centric error highlighting in advanced Lean 4 editors. - Direct Extensibility: Tactic categories and behaviors (e.g., new patterns for
ssrIntroor specialized rewrites) can be user-extended by adding new macro or elaboration rules in Lean, without recompilation or OCaml plugins. - Integrated Backward and Forward Reasoning: Through “views” and the
sby(“solve by …”) tactical, LeanSSR supports both backward chaining (apply-style) and forward reasoning within a single proof mode.
However, LeanSSR does not currently support every SSReflect feature (e.g., unusual intro patterns, large tactics like move: … /negP). Tactic execution relies on evalTactic, and deep macro stacks can impact proof elaboration performance; future Lean versions may address this with improved incremental elaboration. Planned enhancements include integration with Lean 4’s hygienic macro system and tabled typeclass machinery, potentially permitting parameterized SSR patterns.
6. Significance and Prospective Developments
LeanSSR embeds SSReflect’s fine-grained, stepwise reflection methodology within Lean 4 in a purely extensible form, prioritizing unified reasoning, concise proof representation, and high customizability for proof engineers. Case studies show measurable reduction in proof size and increased script clarity in both legacy Mathematical Components imports and native mathlib4 developments. Current limitations center on partial feature parity with Coq’s SSReflect and performance scaling of complex scripts. Planned integration of new Lean 4 metaprogramming infrastructure suggests further expansion of SSR-based methodologies and deeper synergy with core Lean libraries (Gladshtein et al., 2024).