Coq-HoTT VS lean

https://en.wikipedia.org/wiki/Zermelo%E2%80%93Fraenkel_set_t... :

> * Today, Zermelo–Fraenkel set theory [ZFC], with the historically controversial axiom of choice (AC) included, is the standard form of axiomatic set theory and as such is the most common* foundation of mathematics.

Foundation of mathematics: https://en.wikipedia.org/wiki/Foundations_of_mathematics

Implementation of mathematics in set theory:

> The implementation of a number of basic mathematical concepts is carried out in parallel in ZFC (the dominant set theory) and in NFU, the version of Quine's New Foundations shown to be consistent by R. B. Jensen in 1969 (here understood to include at least axioms of Infinity and Choice).

> What is said here applies also to two families of set theories: on the one hand, a range of theories including Zermelo set theory near the lower end of the scale and going up to ZFC extended with large cardinal hypotheses such as "there is a measurable cardinal"; and on the other hand a hierarchy of extensions of NFU which is surveyed in the New Foundations article. These correspond to different general views of what the set-theoretical universe is like

IEEE-754 specifies that float64s have ±infinity and specify ZeroDivisionError. Symbolic CAS with MPFR needn't be limited to float64s.

HoTT in CoQ: Coq-HoTT: https://github.com/HoTT/Coq-HoTT

leanprover-community/mathlib4//

For those interested in formalisation of homotopy type theory, there are several (more or less) active and developed libraries. To mention a few:

UniMath (https://github.com/UniMath/UniMath, mentioned in the article)

Coq-HoTT (https://github.com/HoTT/Coq-HoTT)

agda-unimath (https://unimath.github.io/agda-unimath/)

cubical agda (https://github.com/agda/cubical)

All of these are open to contributions, and there are lots of useful basic things that haven't been done and which I think would make excellent semester projects for a cs/math undergrad (for example).

HoTT is somewhat independent of the choice of proof assistant.

Coq: https://github.com/HoTT/HoTT

Lean: https://github.com/gebner/hott3

idk what you mean by "blue screened", or results being on the way. afaict most of the non-foundational work present (what I assume you mean by "results") in these libraries are basic properties of basic mathematical concepts being rebuilt on HoTT.

The major one for me is version control (git). Imaging having to write a book like HoTT without having revisions and easy way to work on your changes without interfering with anyone else's work and then easily merging everything together.

Apparently, it even still segfaulted in 2018 https://github.com/leanprover/lean/issues/1958. I don't expect my tools to segfault.

Does anyone happen to have the mathlib library in the [low-level format](https://github.com/leanprover/lean/blob/master/doc/export_format.md)? I've been trying to run lean --export to obtain it, but I keep getting various errors.

I have spent a good deal of time trying to formalize elementary mathematics and computer science textbooks in the Lean Theorem Prover, and in trying to extend and improve Lean to make the process easier. I have been able to translate entire chapters of several textbooks into Lean in a natural way, with every line of Lean seemingly isomorphic to the informal presentation. However, once in a while I will hit a statement or proof step that may seem simple to me but that requires a major refactor, or adding new features to Lean itself, or just seems like a brick wall. My brain is able to perform massive refactorings of mathematical knowledge and abstractions, synthesize the equivalent of tens of thousands of lines of tricky and performance-critical software, and maybe even expand the logic I am effectively operating in, all in the blink of an eye.

However, mathlib makes some weird design choices. For example, (semi)groups are defined using multiplicative notation -- and then immediately followed by an entire section giving the exact same definitions using additive notation! The claimed reason for this is that the more abstract approach is inconvenient for automation. I did it in Coq using the abstract approach, and indeed, noticed that doing so broke automation, which I then worked around in various ways. But it's just weird to me as a mathematician to have additive and multiplicative groups be different objects, so I wouldn't want to do it the Lean way come hell or high water. The Lean approach causes practical difficulties as well: you have to prove every theorem about groups twice. In some cases (e.g. product groups), you have to prove every theorem FOUR times. Ugh.