leanprover-community / leanprover-community/mathlib4
Carve out Algebra, Data and Order sublibraries
@YaelDillies is already working on this.
Since Mar 28, 2024.
- Dominant language
- Lean
- Stars
- 4.2k
- Forks
- 1.7k
- PR merge metrics
- No merged PRs in 30d
Description
The bottom part of mathlib is quite a mess. Algebra, data structures and order theory could be developed separately (at least for a while) but are not. Instead, "horizontal" imports keep happening between what would otherwise be three disjoint trees.
The main sources of trouble are
NatandInt, as they are ubiquitous. Their basic properties can be accessed through typeclass-mediated lemmas by importingData.Nat.BasicandData.Nat.Order.Basic. However this comes at the cost of importing basic algebra or basic algebraic order theory where unnecessary. Instead, we can use theNat- andInt-specific lemmas provided by Std.- Many pure algebraic/order theoretic/data structuresque files import non-pure algebraic/order theoretic/data structuresque files just to prove a few properties of an object defined in the non-pure file. In that case, the import can be reversed so that the pure file has pure imports.
- Misplaced files. Eg
Polynomial,RealorSet.Iccare defined underData. The solution is to simply move them to the correct top-level folder.
The purpose of this issue is to collect the PRs doing at least one of the above:
- #11601
- #11633
- #11653
- #11661
- #11711
- #11715
- #11716
- #11725
- #11729
- #11732
- #11741
- #11750
- #11751
- #11753
- #11765
- #11845
Once all these issues will be fixed, we will be able to create three new Lean libraries Algebra, Data, Order, all still living in the current repository.
After such a split, these sublibraries would form a DAG in terms of dependencies. This adds some constraints to future refactors, as that DAG would essentially become immutable.
The benefits?
- working towards it requires drastically cleaning up the import graph, which currently is full of "horizontal gene transfer".
- the sublibrary DAG being immutable is also helpful: it prevents some dependency regressions!
- even though everything will remain in one repository (this is important to minimise the cost of cross-repository refactors), it will be possible in
laketo specify that you only want to depend on a subset of these libraries.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.