lean4 VS coq

Recently replaced by Lean, though.

https://github.com/cedar-policy/cedar-spec

https://lean-lang.org

Nice read! Rust has pushed, and will continue to push, the limits of practical, bare metal, memory safe languages. And it's interesting to think about what's next, maybe eventually there will be some form of practical theorem proving "for the masses". Lean 4 looks great and has potential, but it's still mostly a language for mathematicians. There has been some research on AI constructed proofs, which could be the best of both worlds because then the type checker can verify that the AI generated code/proof is indeed correct. Tools like Kani are also a step forward in program correctness.

Yeah, I believe they said intend for it to be used as a general purpose programming language. I used it to complete Advent of Code last year.

There are some really interesting features for general purpose programming in there. For example: you can code updates to arrays in a functional style (change a value, get a new array back), but if the refcount is 1, it updates in place. This works for inductive types and structures, too. So I was able to efficiently use C-style arrays (O(1) update/lookup) while writing functional code. (paper: https://arxiv.org/abs/1908.05647 )

Another interesting feature is that the "do" blocks include mutable variables and for loops (with continue / break / return), that gets compiled down to monad operations. (paper: https://dl.acm.org/doi/10.1145/3547640 )

And I'm impressed that you can add to the syntax of the language, in the same way that the language is implemented, and then use that syntax in the next line of code. (paper: https://lmcs.episciences.org/9362/pdf ). There is an example in the source repository that adds and then uses a JSX-like syntax. (https://github.com/leanprover/lean4/blob/master/tests/playgr... )

My latest inspiration to use code to a) replace my video editor, b) learn the basics of EDM production and c) understand a few topics in higher maths. This might sound very strange given there are specialised tools for these jobs. There's iMovie / Adobe Premier for video, there's GarageBand and FL studio for music and old good pen and pencil for math proofs. But these tools have three big limitations. First they have a lot of idiosyncratic learning, you have to spend quite some time getting used to these tools and my experience is that this time is quite upsetting. In contrast, you only have to learn to code one, maybe spend a few hours getting used to the syntax of another language. I'm not sure if that's true for most people but it was true for me using the tools mentioned above and wanted a place to discuss and see other people ideas and experiments. The second issue is that all these custom-made tools, are not composing easily. I can't search for all math proofs that used a single theorem. I can't create a plugin for iMovie and apply it to all my videos. I can't pick easily pick a rhythm from the internet and build upon for fun. There's also the issue of costs and version control, all tools I'm using today are open source and my work is stored in my repositories. This way I can create branches and test my ideas and I'm also confident that I can work in these projects in years.

Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+.

https://dafny.org/

https://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

The page summarizing the considered new names and their pros/cons is interesting: https://github.com/coq/coq/wiki/Alternative-names

Naming is hard...

Are those more important than, say:

- Proven with Coq, a formal proof management system: https://coq.inria.fr/

See in the real world: https://aws.amazon.com/security/provable-security/

And check out Computer-Aided Verification (CAV).

To be ruthlessly, uselessly pedantic - after all, we're mathematicians - there's reasonable definitions of "academic" where logical unsoundness is still academic if it never interfered with the reasoning behind any proofs of interest ;)

But: so long as we're accepting that unsoundness in your checker or its underlying theory are intrinsically deal breakers, there's definitely a long history of this, perhaps more somewhat more relevant than the HM example, since no proof checkers of note, AFAIK, have incorporated mutation into their type theory.

For one thing, the implementation can very easily have bugs. Coq itself certainly has had soundness bugs occasionally [0]. I'm sure Agda, Lean, Idris, etc. have too, but I've followed them less closely.

But even the underlying mathematics have been tricky. Girard's Paradox broke Martin-Löf's type theory, which is why in these dependently typed proof assistants you have to deal with the bizarre "Tower of Universes"; and Girard's Paradox is an analogue of Russell's Paradox which broke more naive set theories. And then Russell himself and his system of universal mathematics was very famously struck down by Gödel.

But we've definitely gotten it right this time...

[0] https://github.com/coq/coq/issues/4294

Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+.

https://dafny.org/

https://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

Still, there are many useful tools based on these ideas, used by programmers and mathematicians alike. What you describe sounds rather like Datalog (e.g. Soufflé Datalog), where you supply some rules and an initial fact, and the system repeatedly expands out the set of facts until nothing new can be derived. (This has to be finite, if you want to get anywhere.) In Prolog (e.g. SWI Prolog) you also supply a set of rules and facts, but instead of a fact as your starting point, you give a query containing some unknown variables, and the system tries to find an assignment of the variables that proves the query. And finally there is a rich array of theorem provers and proof assistants such as Agda, Coq, Lean, and Twelf, which can all be used to help check your reasoning or explore new ideas.

What ever happened to the effort [1] to rename Coq in order to make it less offensive? There were a number of excellent proposals [2] that seemed to die on the vine.

[1] https://github.com/coq/coq/wiki/Alternative-names

[2] https://github.com/coq/coq/wiki/Alternative-names#c%E1%B5%A3...

Information about the Coq proof assistant: https://coq.inria.fr/ , https://en.wikipedia.org/wiki/Coq

This type of thing can help you formally verify code.

So, if your proof is correct, and your description of the (language/CPU) is correct, you can prove the code does what you think it does.

Formal proof systems are still growing up, though, and they are still pretty hard to use. See Coq for an introduction: https://coq.inria.fr/

Most of the proof assistants out there: Lean, Coq, Dafny, Isabelle, F*, Idris 2, and Agda. And the main concepts are dependent types, Homotopy Type Theory AKA HoTT, and Category Theory. Warning: HoTT and Category Theory are really dense, you're going to really need to research them.