Bachelor- und Masterarbeiten

When writing tactics for the Lean theorem prover, we often match on Lean expressions. or example, a tactic that splits hypotheses h : A ∧ B into h₁ : A and h₂ : B goes through each hypothesis in the context, looking for a type that matches the pattern ?A ∧ ?B. The quote4 library allows us to conveniently perform such matching.

However, quote4 does not currently support matching up to computation. For example, if we define a type synonym T := A ∧ B, then we might expect the conjunction-splitting tactic to recognise and split the hypothesis h : T. The necessary logic is quite tedious and must currently be written by hand. The aim of this project is to extend QQ with a new matching construct that performs matching up to computation, automatically and efficiently. More details are available here.

To do so, you will first have to familiarise yourself with the metaprogramming APIs of Lean. A solid command of functional programming, including monads, is required. Experience using theorem provers based on dependent type theory (e.g. Agda, Coq, Lean) would be very helpful. The project is suitable for a master or strong bachelor student.

The Lean theorem prover is built on a fairly minimal core type theory. By design, Lean itself is not particularly trustworthy (e.g. it allows users to circumvent its type system in ways that are hard to detect), but it can export finished proofs, which are terms of the core type theory. These can then be checked by small, trustworthy third-party checkers (1, 2, 3).

The aim of this project is to build one such checker (though we may limit the scope to a subset of the core type theory). To do so, you'll have to familiarise yourself with the rules of the core type theory and then define its abstract syntax and write a parser and typechecker.

Familiarity with basic compilation techniques (parsing, abstract syntax, typechecking) is required. Experience with dependent type theories would be very helpful. The project is suitable for a master or strong bachelor student.

The Lean theorem prover has a very flexible parsing mechanism which allows us to embed other languages into it. In this project, we'd like to use this mechanism to embed intensional or extensional Martin Löf type theory. This means you'll have to define the abstract syntax and type system of this type theory in Lean and write a parser type checker for it. (We aim to use the embedded type theory to simplify proofs about its categorical models.)

A solid command of functional programming is required, as is familiarity with basic compilation techniques (parsing, abstract syntax, typechecking). Experience using theorem provers based on dependent type theory (e.g. Agda, Coq, Lean) would be very helpful. The project is suitable for a master or strong bachelor student.

Lifting is a technique to produce hard instances of CNF formulas from easier ones. In a recent paper [1], a lower bound for proofs of certain lifted formulas in the regular resolution proof system was shown. For these formulas, upper bounds in a stronger proof systems related to clause learning [2] should be derived.

[1] Vinyals, Elffers, Johannsen, Nordström, "Simplified and Improved Separations between Regular and General Resolution by Lifting", SAT 2020

[2] Buss, Hoffmann, Johannsen, "Resolution Trees with Lemmas: Resolution Refinements that Characterize DLL-Algorithms with Clause Learning", LMCS 4, 2008.

The Lean theorem prover has various tactics for rewriting with equations. For example, given the equation h : n = m, we can call rw [h] to replace every n in our current goal with m. However, these tactics only work for equality, whereas in practice we sometimes want to rewrite with other relations as well. For example, if two groups G, H are isomorphic, we should be able to replace G with H in any statement about groups.

The Coq theorem prover has a tactic which implements such 'generalised' rewriting. The aim of this project is to port this tactic to Lean. An early proof of concept implementation for Lean is available.

To tackle this project, you will first have to familiarise yourself with the metaprogramming APIs of Lean. A solid command of functional programming, including monads, is required. Experience using theorem provers based on dependent type theory (e.g. Agda, Coq, Lean) would be very helpful.

In the Lean theorem prover, we usually write proofs in an imperative tactic language, so a proof is a series of commands. A problem with this style is that the proofs are very hard to read and sometimes also hard to maintain.

A master student of ours therefore wrote a tool which transforms an imperative proof into a 'structured' proof, where the steps are annotated with additional information about the expected proof state. However, this tool is currently just a proof of concept and not suitable for serious use. The aim of this project is to change that, polishing the tool and integrating it into the Lean extension for the VSCode editor.

To tackle this project, you may have to familiarise yourself with some of the metaprogramming APIs of Lean, for which a solid command of functional programming, including monads, is required. Experience with theorem provers based on dependent type theory (e.g. Agda, Coq, Lean) and with editor extensions for programming languages (particularly VSCode, which is implemented in JavaScript, and the language server protocol) would be helpful.

In the Lean theorem prover, some tasks, such as proving the continuity of a function or a linear inequality, can be automated by using some sort of specific strategy. For example, the `continuity` tactic uses a general theorem prover restricted to some set of lemmas that concern continuity to complete a goal.

This project aims to improve existing specialised tactics available in Mathlib or create new ones that would solve particular types of goals.

To tackle this project, you will have to familiarise yourself with some of the metaprogramming APIs of Lean, for which a solid command of functional programming, including monads, is required. Experience with theorem provers based on dependent type theory (e.g. Agda, Coq, Lean) would be helpful.

Satisfiability modulo theories (SMT) solvers, such as CVC5, are utilized in various applications including program verification, program synthesis, symbolic execution, and test case generation. These solvers can determine the satisfiability of first- and higher-order formulas with respect to multiple theories, allowing them to reason about diverse data types and data structures.

A common method to test SMT solvers is by using input formulas that are either satisfiable or unsatisfiable by design. This approach enables the detection of soundness bugs in an SMT solver by comparing the solver's output with the expected result. Through this method, we can not only demonstrate the soundness of SMT solvers but also extend them based on the anticipated outcomes from these formulas.

The Satisfiability modulo theories (SMT) solver CVC5 produces proofs in an internal proof calculus that faithfully reflects its reasoning. Here is a comprehensive description of the proof rules. Optionally, CVC5 can convert and output its internal proofs into the following external formats:

1. Alethe
2. LFSC
3. DOT

Goal of this project is to convert the generated proofs into a human-readable mathematical format.

Sledgehammer is a highly popular tool for the Isabelle proof assistant that integrates third-party automatic theorem provers. Some automatic provers, such as Vampire, provide support for induction. The goal of this project would be to integrate such support in Sledgehammer, so that Isabelle users can get proofs by induction for free.

SMT solvers are general-purpose tools for solving logic problems expressed in logic and arithmetic. They can be used to solve various puzzles. In this project, you will develop an encoding of the game Str8ts in SMT.

This type of thesis aims to define and then prove some interesting properties about a mathematical concept, system, structure, or implementation, using either Isabelle [1] or Lean [2]. There exists a wide variety of possible formalization projects; you may either come to us with an idea of your own, or we look for one in a field that interests you.

For a project like this, prior experience with either Lean or Isabelle (or another proof assistant like Coq [3] or Agda [4]) is very helpful but not strictly required if you are willing to learn to use them in the process. For Master's level, due to the probable scope of the project, not having prior experience might prove to be challenging, though.
Resources: Lean 4 learning material, Isabelle Tutorial, Concrete Semantics with Isabelle/HOL, Functional Data Structures and Algorithms.

[1] https://isabelle.in.tum.de/
[2] https://lean-lang.org/
[3] https://coq.inria.fr/
[4] https://agda.readthedocs.io/en/v2.6.0.1/index.html

Some interesting projects:

Verification of homework sheets:

We would like to find out how viable and helpful it is to verify homework sheets (e.g. for the lecture "Logik und diskrete Strukturen"). Also possible automations can be explored.

Verified Ordered Resolution:

We verified the Superposition Calculus for first order logic using the Saturation Framework in Isabelle. The same verficiation strategy could be also applied to verify Ordered Resolution for first order logic.

Diff-Arrays:

Functional lists are a convenient and easy-to-use data structure in functional programming. However, compared to imperative arrays, lookup and update operations on lists have a significantly worse runtime of O(n) instead of O(1). For this reason, we created an automatic refinement of linearly used lists to arrays and also non-linearly used lists to diff arrays. Diff arrays are persistent and store their updates in a tree-like structure next to a plain array. With them, we can have lookup and update operations in O(1) for its most recent version. Parallel to the refinement, we will automatically create equivalence proofs using the Isabelle/HOL theorem prover and its Imperative/HOL and separation logic facilities to ensure that the two versions of the program are doing the same.
Repository
In the future work chapter of this thesis, you can see the open tasks in this endeavor. All four tasks described there would give a good entry point to a Master's or Bachelor's thesis.

Functional Real-Time Deque:

Based on the work of Chuang and Goldberg, we implemented and formally verified a double-ended queue (deque) in a purely functional language such that each enqueue and dequeue operation on either end takes O(1) time in the worst case. This is what real-time means. Operations on previous versions of a deque are in constant time since purely functional data structures are persistent by default.
Paper: https://drops.dagstuhl.de/opus/volltexte/2023/18404/pdf/LIPIcs-ITP-2023-29.pdf
Entry in the AfP: https://www.isa-afp.org/entries/Real_Time_Deque.html

However, we do not support the catenation of deques. This paper by Kaplan and Tarjan describes a fully functional implementation of a real-time deque with catenation: https://dl.acm.org/doi/abs/10.1145/324133.324139
We found an actual implementation of it in OCaml: https://github.com/art-w/deque
A good entry point to your Master's or Bachelor's thesis could be re-implementing this data structure in a functional programming language of your choice and comparing it to the Deque implementation without catenation based on Chuang and Goldberg.

The tooling of theorem provers is often lagging behind compared to main stream programming languages. Improvements are always welcome. This is also the case for Isabelle.

Some interesting projects:

AI Search

It is often tedious to find out if certain theorems already exist in the Isabelle Library or the Afp. An AI search tool could be helpful!

Jedit Dark mode

Jedit, the main IDE for Isabelle, does not/just partially support dark mode: Dive into the rendering options of Isabelle and create new, consistent and good-looking color schemes. (Also the options menu in general could use a rework.)

Isabelle minted

Improve support for Isabelle in the minted Latex package.

Improve Visual Studio Code Plugin

Better than improving Jedit would be to fully replace it by Visual Studio Code. The VS Code Plugin for Isabelle needs some improvements though.

Open projects in Jedit

Often Isabelle projects cannot be opened from within Jedit, because they need some CLI Arguments. Add this functionality.

Aesop is a proof search tool developed by Jannis Limperg for the Lean 4 theorem prover. It runs various Lean tactics in an attempt to automatically find proofs of 'trivial' propositions. Currently, these tactics perform type-level computations, which are a core feature of Lean's type system, lazily, i.e. only when such computations are necessary. This has generally been found to be the most efficient way to implement Lean and similar theorem provers.

However, in the context of Aesop, we often operate on the same or very similar expressions multiple times, so it may be more efficient to perform all type-level computations at once (i.e., to normalise the expressions). Additionally, normalisation would allow us to use a variety of techniques from automated theorem proving, e.g. very efficient indexing methods. Hence the goal of this project is to implement eager normalisation (and possibly some follow-up optimisations) and to evaluate whether this indeed increases Aesop's performance.

Many programming languages feature some form of type inference, which lets the compiler fill in certain type annotations omitted by programmers. For embedded domain-specific languages (EDSLs), a type inference algorithm must usually be developed and implemented from scratch. This is cumbersome, so EDSLs often end up having poor type inference.

The Lean 4 theorem prover offers a possible alternative. It gives programmers full access to its own elaborator, which infers implicit arguments and type-class instances. This means we can use Lean's elaborator as a type inference procedure for any DSL embedded in Lean, provided that the EDSL's type inference problems can be encoded as elaboration problems.

The project will explore this possibility by implementing a toy functional EDSL with type inference. The type inference problems of this language should map almost trivially to elaboration problems. If time permits, we could also look into adding type classes to the EDSL.

The project requires solid functional programming skills (including monads) and the willingness to learn Lean's compiler APIs. Experience writing compilers or interpreters would be helpful. The project is suitable for a master or strong bachelor student.

In the Lean 4 theorem prover, tactics are used to generate proof terms (i.e., programs in Lean's programming language). These terms are usually generated right away when a tactic is run. However, in the context of proof search tools such as our Aesop, we execute many tactics speculatively to see whether they lead to a successful proof. When Aesop finds a proof, we only need proof terms for those tactics that were used in the proof, and not for any other tactics executed during the search. It would therefore be advantageous if we could generate proof terms lazily, deferring their construction until we know which ones we actually need. Our hypothesis is that this would substantially boost the performance of many Aesop invocations.

The aim of this project is to test this hypothesis. Since fully lazy proof generation would entail major changes to Lean's APIs, we do not aim for a full implementation. Instead, we would implement a mode that simply skips proof generation completely. This would give us an upper bound of the performance gains that could be obtained through lazy proof generation.

The project requires solid functional programming skills (including monads) and the willingness to learn Lean's compiler APIs. The project is suitable for a strong bachelor student.