Interesting. It's essentially the same idea as in this article: <a href="https://substack.com/home/post/p-184486153" rel="nofollow">https://substack.com/home/post/p-184486153</a>. In both scenarios, the human is relieved of the burden of writing complex formal syntax (whether Event-B or Lean 4). The human specifies intent and constraints in natural language, while the LLM handles the work of formalization and satisfying the proof engine.<p>But Lean 4 is significantly more rigid, granular, and foundational than e.g. Event-B, and they handle concepts like undefined areas and contradictions very differently. While both are "formal methods," they were built by different communities for different purposes: Lean is a pure mathematician's tool, while Event-B is a systems engineer's tool. Event-B is much more flexible, allowing an engineer (or the LLM) to sketch the vague, undefined contours of a system and gradually tighten the logical constraints through refinement.<p>LLMs are inherently statistical interpolators. They operate beautifully in an <i>Open World</i> (where missing information is just "unknown" and can be guessed or left vague) and they use <i>Non-Monotonic Reasoning</i> (where new information can invalidate previous conclusions). Lean 4 operates strictly on the <i>Closed World Assumption</i> (CWA) and is brutally <i>Monotonic</i>. This is why using Lean to model things humans care about (business logic, user interfaces, physical environments, dynamic regulations) quickly hits a dead end. The physical world is full of exceptions, missing data, and contradictions. Lean 4 is essentially a return to the rigid, brittle approach of the 1980s expert systems. Event-B (or similar methods) provides the logical guardrails, but critically, it tolerates under-specification. It doesn't force the LLM to solve the <i>Frame Problem</i> or explicitly define the whole universe. It just checks the specific boundaries the human cares about.
So basically you are arguing a Type Theory vs Set Theory problem, Foundationalism or Engineering Refinement. Since we read here of multiple use cases for LLMs in both CS divides, we can conclude an eventual convergence in these given approaches; and if not that, some formal principles should emerge of when to use what.
This discussion started already in the sixties (see e.g. the 1969 publication by McCarthy and Hayes where they describe the "frame problem" as a fundamental obstacle to the attempt to model the dynamic world using First-Order Logic and monotonic reasoning). A popular attempt to "solve" this problem is the Cyc project. Monotonic logic is universally understood as a special, restricted case (a subset) of a broader non-monotonic theory.
I just completed the formal verification of my bachelor thesis about real time cellular automata with Lean 4, with heavy use of AI.<p>Over the past year, I went from fully manual mode (occasionally asking chat gpt some Lean questions) to fully automatic mode, where I barely do Lean proofs myself now (and just point AI to the original .tex files, in German).
It is hard to believe how much the models and agentic harnesses improved over the last year.<p>I cannot describe how much fun it is to do refactorings with AI on a verified Lean project!<p>Also, it's so easy now to have visualizations and typesetted documents generated by AI, from dependency visualizations of proofs using the Lean reflection API, to visual execution traces of cellular automatas.
Lean is a great idea, especially the 4th version, a huge level up from the 3rd one, but its core still deficient[1] in some particular scenarious (see an interesting discussion[2] in the Rock (formerly Coq) issue tracker). Not sure if it might hinder the automation with the AI.<p>[1] <a href="https://artagnon.com/logic/leancoq" rel="nofollow">https://artagnon.com/logic/leancoq</a><p>[2] <a href="https://github.com/rocq-prover/rocq/issues/10871" rel="nofollow">https://github.com/rocq-prover/rocq/issues/10871</a>
This has been the approach taken by some using LLMs, even in less type-heavy situations. Of course, it is part of a broader tradition in which search is combined with verification. Genetic programming and related areas come to mind. Here, LLMs are search, while Lean is used to express constraints.
I am using lean as part of the prd.md description handed to a coding agent. The definitions in lean compile and mean exactly what I want them to say. The implementation i want to build is in rust.<p>HOWEVER … I hit something i now call a McLuhen vortex error: “When a tool, language, or abstraction smuggles in an implied purpose at odds with your intended goal.”<p>Using Lean implies to the coding agent ‘proven’ is a pervasive goal.<p>I want to use lean to be more articulate about the goal. Instead using lean smuggled in a difficult to remove implicit requirement that everything everywhere must be proven.<p>This was obvious because the definitions i made in lean imply the exact opposite of everything needs to be proven. When i use morphism i mean anything that is a morphism not only things proven to be morphisms.<p>A coding agent driven by an llm needs a huge amount of structure to use what the math says rather than take on the implications that because it is using a proof system therefore everything everywhere is better if proven.<p>The initial way i used lean poisoned the satisficing structure that unfolds during a coding pass.
If you want to mess with this at home, I've been vibe coding <a href="https://github.com/kig/formalanswer" rel="nofollow">https://github.com/kig/formalanswer</a> to plug theorem provers into an LLM call loop. It's pretty early dev but it does have a logic rap battle mode.
I think I saw Terence Tao use a formal proof language but I don't remember if it was Lean. I'm not familiar with it but I do agree that moving to provable languages could improve AI but isn't the basis just having some immutable rigorous set of tests basically which could be replicated in "regular" programming languages?
You can think of theorem provers as really crazy type checkers. It's not just a handful of tests that have to run, but more like a program that has to compile.
Yes exactly. There is this thing called the “Curry-Howard Isomorphism” which (as I understand it) says that propositions in formal logic are isomorphic to types. So the “calculus of constructions” is a typed lambda calculus based on this that makes it possible for you to state some proposition as a type and if you can instantiate that type then what you have done is isomorphic to proving the proposition. Most proof assistants (and certainly Lean) are based on this.<p>So although lean4 is a programming language that people can use to write “normal” programs, when you use it as a proof assistant this is what you are doing - stating propositions and then using a combination of a (very extensive) library of previous results, your own ingenuity using the builtins of the language and (in my experience anyway) a bunch of brute force to instantiate the type thus proving the proposition.
It was lean4. In fact he has made lean4 versions of all of the proofs in his Analysis I textbook available here<p><a href="https://github.com/teorth/analysis" rel="nofollow">https://github.com/teorth/analysis</a><p>He also has blogged about how he uses lean for his research.<p>Edit to add: Looking at that repo, one thing I like (but others may find infuriating idk) is that where in the text he leaves certain proofs as exercises for the reader, in the repo he turns those into “sorry”s, so you can fork the repo and have a go at proving those things in lean yourself.<p>If you have some proposition which you need to use as the basis of further work but you haven’t completed a formal proof of yet, in lean, you can just state the proposition with the proof being “sorry”. Lean will then proceed as though that proposition had been proved except that it will give you a warning saying that you have a sorry. For something to be proved in lean you have to have it done without any “sorry”s. <a href="https://lean-lang.org/doc/reference/latest/Tactic-Proofs/Tactic-Reference/#sorry" rel="nofollow">https://lean-lang.org/doc/reference/latest/Tactic-Proofs/Tac...</a>
Yes, though often the easiest way to replicate it in regular programming languages is to translate that language to Lean or another ITM, though auto-active like Verus is used for Rust pretty successfully.<p>Python and C though have enough nasal demons and undefined behavior that it's a huge pain to verify things about them, since some random other thread can drive by and modify memory in another thread.
> Large language models (LLMs) have astounded the world with their capabilities, yet they remain plagued by unpredictability and hallucinations – confidently outputting incorrect information. In high-stakes domains like finance, medicine or autonomous systems, such unreliability is unacceptable.<p>This misses a point that software engineers initmately know especially ones using ai tools:<p>* Proofs are one QA tool<p>* Unit tests, integration tests and browser automation are other tools.<p>* Your code can have bugs because it fails a test above BUT...<p>* You may have got the requirements wrong!<p>Working with claude code you can have productive loops getting it to assist you in writing tests, finding bugs you hadn't spotted and generally hardening your code.<p>It takes taste and dev experience definitely helps (as of Jan 26)<p>So I think hallucinations and proofs as the fix is a bit barking up the wrong tree<p>The solution to hallucinations is careful shaping of the agent environment around the project to ensure quality.<p>Proofs may be part of the qa toolkit for AI coded projects but probably rarely.
The real value is in mixed mode:<p>- Lean supports calling out as a tactic, allowing you to call LLMs or other AI as judges (ie, they return a judgment about a claim)<p>- Lean can combine these judgments from external systems according to formal theories (ie, normal proof mechanics)<p>- an LLM engaged in higher order reasoning can decompose its thinking into such logical steps of fuzzy blocks<p>- this can be done recursively, eg, having a step that replaces LLM judgments with further logical formulations of fuzzy judgments from the LLM<p>Something, something, sheaves.
I like a lot of the idea behind such theorem provers, however, I always have issues with them producing compatible code with other languages.<p>This happened to me with idris and many others, I took some time to learn the basics, wrote some examples and then FFI was a joke or code generators for JavaScript absolutely useless.<p>So no way of leveraging an existing ecosystem.
Lean has standard c ABI FFI support. <a href="https://lean-lang.org/doc/reference/latest/Run-Time-Code/Foreign-Function-Interface/" rel="nofollow">https://lean-lang.org/doc/reference/latest/Run-Time-Code/For...</a>
Literally the first line of the link:<p>“The current interface was designed for internal use in Lean and should be considered unstable. It will be refined and extended in the future.“<p>My point is that in order to use these problem provers you really gotta be sure you need them, otherwise interaction with an external ecosystem might be a dep/compilation nightmare or bridge over tcp just to use libraries.
Apart from prioritizing FFI (like Java/Scala, Erlang/Elixir), the other two easy ways to bootstrap an integration of a new obscure or relatively new programming language is to focus on RPC (ffi through network) or file input-output (parse and produce well known file formats to integrate with other tools at Bash level).<p>I find it very surprising that nobody tried to make something like gRPC as an interop story for a new language, with an easy way to write impure "extensions" in other languages and let your pure/formal/dependently typed language implement the rest purely through immutable message passing over gRPC boundary. Want file i/o? Implement gRPC endpoint in Go, and let your language send read/write messages to it without having to deal with antiquated and memory unsafe Posix layer.
[flagged]
[flagged]