Earlier quoted context omitted.
[flagged]
Does that mean your production code is lean? Or do you translate some other language code to lean to verify it?
Leanstral: Open-source agent for trustworthy coding and formal proof engineering
161–170 of 234 posts
Re: Leanstral: Open-source agent for trustworthy coding and formal proof engineering
#162The real world success they report reminds me of Simon Willison’s Red Green TDD: https://simonwillison.net/guides/agentic-engineering-pattern... > Instead of taking a stab in the dark, Leanstral rolled up its sleeves. It successfully built test code to recreate the failing environment and diagnosed the underlying issue with definitional equality. The model correctly identified that because def creates a rigid definit…
If Agent is writing the tests itself, does it offer better correctness guarantees than letting it write code and tests?
Re: Leanstral: Open-source agent for trustworthy coding and formal proof engineering
#163AI agents will become a comodity. Europeans not wanting to be dependent, and they are giving for free what US investors planed to charge with 90% margin. Amazing! What a blast. Thank you for your service (this first 100M$ burned to POC GPT1 and from here, we are so good to go)
The problem with the European independence story is, that it seems Mistral runs its own stuff also on US cloud act affected infrastructure. This makes them a very weird value proposition: If I accept a level of "independence" whereby I run on AWS or Azure, I could as well pay for Anthropic or GPT to have SOTA performance. If I do not accept that level of independence but want more, I need to buy what's on OVH, Scalew…
Re: Leanstral: Open-source agent for trustworthy coding and formal proof engineering
#164Naturally the Microsoft-owned language is getting the AI hype instead of the more mature options that could do this sort of work… Agda, ATS, Coq/Rocq, Dafny, Fstar, Idris, Isabelle, Why3 just to name a few.
Re: Leanstral: Open-source agent for trustworthy coding and formal proof engineering
#165Earlier quoted context omitted.
>Such is very difficult at the moment What do you mean? It's a nice and simple language. Way easier to get started than OCaml or Haskell for example. And LLMs write programs in Lean4 with ease as well. Only issue is that there are not as many libraries (for software, for math proofs there is plenty). But for example I worked with Claude Code and implemented a shell + most of unix coreutils in like a couple of hours.…
Well, if you do not need to care about performance everything can be extremely simple indeed. Let me show you some data structure in coq/rocq while switching off notations and diplaying low level content. Require Import String. Definition hello: string := "Hello world!". Print hello. hello = String (Ascii.Ascii false false false true false false true false) (String (Ascii.Ascii true false true false false true true f…
Re: Leanstral: Open-source agent for trustworthy coding and formal proof engineering
#166Earlier quoted context omitted.
I don't know why you created a new account for this, but take the textbook example of a nontrivial formally verified system: SeL4. That implementation was 8.7k of C code, which correspondend to 15k lines of Isabelle that ultimately needed 100k+ lines of proof to satisfy. And that was with the formal model excluding lots of important properties like hardware failure that actual systems deal with.
You are confusing the proof with the spec/theorem. A correct proof and a valid proof are the same thing. It doesn't really matter how long the proof is, and you don't even need to understand it for it to be correct, the machine can check that. But indeed, if the spec includes 8.7k of C code, that is problematic. If you cannot look at the theorem and see that it is what you mean, that is a problem. That is why abstrac…
Knowing whether those theorems are the right theorems for the problem can be as difficult as understanding the implementation itself. Hence the example of SeL4 where the number of theorems exceeds lines of code in the original implementation and the formal model is large.
It's my experience that most people doing formal methods have seen cases where they actually proved something slightly different than what they intended to. This usually involves an unintentional assumption that isn't generally true.
Re: Leanstral: Open-source agent for trustworthy coding and formal proof engineering
#167Earlier quoted context omitted.
Tests (and type-checkers, linters, formal specs, etc.) ground the model in reality: they show it that it got something wrong (without needing a human in the loop). It's empiricism, "nullius in verba"; the scientific approach, which lead to remarkable advances in a few hundred years; that over a thousand years of ungrounded philosophy couldn't achieve.
This only holds if you understand what's in the tests, and the tests are realistic. The moment you let the LLM write the tests without understanding them, you may as well just let it write the code directly.