Lean 4 fork for HoTT-compatible kernel extensions (Path types, transport, HITs). Maintained against upstream leanprover/lean4.
9f47e08ecc
This PR imports LeanSAT's LRAT module as step 4/~6 (step 7 could go after I did some refactorings to import this) of the LeanSAT upstreaming. It is the last large component, after this only the LRAT parser and the reflection tactic that hooks everything up to the meta level remains. In particular it is the last component that contains notable proofs, yay! Again a few remarks: 1. Why is this not in `Std`? I'm not quite sure whether it should be there. At the current level of code/proof quality we can certainly not import the checker itself into `Std` but maybe having the data type as well as the trimming algorithm there might be of interested? I'm hoping that as we refactor the checker in the future its quality will be high enough to be also put into `Std`. At this point we would have a full AIG -> CNF -> LRAT verification pipeline in `Std` for everyone to use. One additional blocker in this is that we cannot provide the parsers for the format in `Std` as of today because `Parsec` is still in `Lean` so that would also have to change. 2. There do exist two abstraction levels to make sure we can swap out the LRAT implementation at any time: - The public interface is just all files in the top level `LRAT` directory. It basically only contains the LRAT format itself, the checker + soundness proof and the trimming algorithm. As long as we don't need to change their API (which we shouldn't have to I think) we can always swap out the entire `Internal` directory without breaking anything else in LeanSAT. - The `Internal` module itself contains another layer of abstraction in the form of the `Formula` class. This allows us to swap out the most complex component in `Internal` as well, without having to touch any of the infrastructure that is built around it either. 3. I mostly performed stylistic cleanups on the `Internal` module. In my experience over upgrading to many nightlies during the course of LeanSAT development, I have gotten these proofs cleaned up to the point, where they only break if we change the `List` or `Array` proof API significantly. Given that we are currently in the process of stabilizing it I'm hoping that these proofs do not have to be touched anymore unless we do something crazy. All of the custom theory that the LRAT component developed around various basic data types has been upstreamed into Lean over the course of various other PRs. 4. If there are some simple tricks that we can pull off to increase the code / proof quality in `Internal` and in particular `Internal.Formula` (this module is not for the light-hearted Lean reviewer) I'm all for it. Otherwise the best course of action to provide LeanSAT to our users soon would probably be to merge it as is and do a cut + rewrite at one of the two interface points described above. |
||
|---|---|---|
| .github | ||
| doc | ||
| images | ||
| nix | ||
| releases_drafts | ||
| script | ||
| src | ||
| stage0 | ||
| tests | ||
| .gitattributes | ||
| .gitignore | ||
| .ignore | ||
| CMakeLists.txt | ||
| CMakePresets.json | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| flake.lock | ||
| flake.nix | ||
| lean-toolchain | ||
| lean.code-workspace | ||
| LICENSE | ||
| LICENSES | ||
| README.md | ||
| RELEASES.md | ||
This is the repository for Lean 4.
About
- Quickstart
- Homepage
- Theorem Proving Tutorial
- Functional Programming in Lean
- Manual
- Release notes starting at v4.0.0-m3
- Examples
- External Contribution Guidelines
- FAQ
Installation
See Setting Up Lean.
Contributing
Please read our Contribution Guidelines first.
Building from Source
See Building Lean (documentation source: doc/make/index.md).