Memories: doing my PhD at Stanford, under John L Hennessy

Fri, 13 Feb 2026 00:00:00 +0000

When young researchers get together, one topic of conversation is “who supervised your PhD?” Back in the day, Rod Burstall was often named. Also mentioned were Robin Milner, Dana Scott and Gordon Plotkin. Then it would be my turn: “John Hennessy”. Who? Even today, while everyone has heard of Mark Zuckerberg and Bill Gates, few people can name the guy who is in charge of Google’s sprawling empire. But even those who got past the “who?” would then be asking “why?”

Early years at Stanford

I arrived in the autumn of 1977. It was not a good time for me. After a year of drifting, I found myself in the group of David Luckham and his Stanford Pascal Verifier. It consisted of a verification condition generator for Pascal coupled with a rewriting engine for proving the assertions generated. The user had to supply the rewrite rules, which had to be trusted: a major weakness. I worked on verifying list processing programs for a while (simple things like append and reverse), but came a cropper when I noticed that the rewrite rules for lists that I had been given were inconsistent.

Luckham had a strong group. In particular, Greg Nelson and Derek Oppen made contributions that are still used today in most SMT solvers:

congruence closure, whereby all available equalities are propagated throughout a formula
a cooperation framework for combining decision procedures

In addition, Derek Oppen created a framework for pretty printing that I adopted every chance I got, which means it is now in HOL4, Isabelle and the Poly/ML implementation of Standard ML. Unfortunately, David Luckham had a reputation for exploiting his PhD students; I was even taken aside, probably by the kind and lovely departmental secretary, Carolyn Tajnai, and advised to watch out. Unfortunately, I was by nature inattentive, so I didn’t take heed and I didn’t even notice when (allegedly) Luckham told me that I should move on. But I did notice when my financial support disappeared.¹ Enter John.

Working with John Hennessy

My first impression was that John looked incredibly young. Compared with Luckham and many other Stanford professors, he was practically a baby (he was 27). It must’ve been a challenge for him as well as myself. I was there because I had gotten into trouble and needed funding, which is not the most promising start for the professor/student relationship. I was interested in programming languages and theory, while his speciality was computer architecture. Somehow we arrived at a PhD project involving theory (denotational semantics) and practice (in the form of compiler generation). Somehow I started building the thing. At first it wasn’t working, then it was. I had built a semantics-directed compiler generator consisting of three components:

a Grammar Analyser, which took a programming language specification in the form of an attribute grammar decorated with formulas of denotational semantics
a Universal Translator, which functioned as a compiler for the specified language
a Stack Sachine, for executing the generated code

The performance penalty for the generated object code was a factor of 1000, but who’s counting?

To support myself, generally I worked as a Teaching Assistant and gave the occasional lecture standing in for John, but on the whole I was simply able to get on with my research. And at the end when I had finished too quickly to satisfy Stanford’s residence requirement, John even found the money to pay the difference. (You can’t do that at Cambridge, but the residence requirement is only three years.)

At Stanford, like in many other universities, the PhD defence is a public event. Moreover, the candidate is supposed to bring refreshments, generally something like donuts. I decided to bring milk and cookies. This was a stupid idea. I wasn’t good at baking cookies (a housemate helped me out when it all went wrong), and it isn’t wise to pretend that your PhD defence is some sort of kindergarten.

Watching him rise and rise

After getting my PhD, and with John’s advice and help, I found myself at Cambridge. While mostly preoccupied with my research, I got occasional news from Stanford. John’s career trajectory went like this:

1989: Director of the Computer System Laboratory [a research unit within the CS department]
1994: Chairman of the Computer Science Department
1996: Dean of the School of Engineering
1999: Provost of Stanford University
2000: President of Stanford University

He remained President of Stanford until 2016. Where does one go up from there? President of the USA would be a weak and frustrating role, at least back in that quaint time when the President’s powers were limited by the US Constitution. If you really want to be master of the universe, take charge of Google. He did that in 2018.

Up until now I have not mentioned John’s research. (I was not one to follow developments in computer architecture.) John, with David Patterson, made fundamental contributions to the development of RISC technology and wrote two acclaimed textbooks. John was also a founder of MIPS Computer Systems. His work has been recognised by the ACM’s Turing Award and numerous other honours and prizes. If your computer is fast, one of the people you should thank is John.²

As an influence

If asked whom I see as role models, I typically mention Richard Feynman and John Hennessy. It may be ridiculous to name Nobel and Turing laureates, but why not aim high? Seriously, what I tried to emulate is not genius or ambition, but their willingness to engage with students. Feynman, despite his celebrity, went out of his way to communicate his knowledge to lowly undergraduates, never hiding behind mathematical formulas but revealing their link to natural phenomena. John did not understand exactly what I was doing. But he had already grasped that this was not necessary. It is enough to guide the student through the labyrinth of the PhD process, keeping an eye on their progress and recognising when they needed help. Think of a General Practitioner who has overall familiarity with their patient’s health situation and knows when to refer them to a specialist.

John visited Cambridge during the 1990s, perhaps interested in taking up a position here. So in a plausible alternative future, he might now be the British Prime Minister.

I was not unhappy to learn, years later, about an unfortunate situation involving airport security that got Luckham an invitation to spend a night in a police cell. ↩
And if it is slow, probably you should be blaming Bill Gates. ↩

Broken proofs and broken provers

Thu, 15 Jan 2026 00:00:00 +0000

People expect perfection. Consider the reaction when someone who has been vaccinated against a particular disease nevertheless dies of it. Mathematical proof carries the aura of perfection, but again people’s expectations will sometimes be dashed. As outlined in an earlier post, the verification of a real world system is never finished. We can seldom capture 100% of reality, so failure remains possible. Even in a purely mathematical proof, there are plenty of ways to screw up. Plus, proof assistants have bugs.

Some badly broken proofs

Many years ago, I refereed a paper about the verification of some obscure application. I recall that the theoretical framework depended on several parameters, among them $z$, a nonzero complex number. This context was repeated for all the theorems in the paper: each included the assumption $\forall z.\, z\not=0$. Needless to say, that assumption is flatly false. The author of the paper had presumably intended to write something like $\forall z.\, z\not=0 \to \cdots$. The error is easy to overlook, and I only became suspicious because the proofs looked too simple. The entire development was invalid.

Isabelle would have helped here. For one thing, Sledgehammer warns you if it detects a contradiction in your background theory. And also, when you have a series of theorems that all depend on the same context, you can prove them within a locale, with assumptions such as $z\not=0$ laid out clearly. Even without locales, the Isabelle practice of listing the assumptions separately in the theorem statement would have avoided the problem. Isabelle newbies frequently ask why we prefer inference rules with explicit premises and conclusions over formulas like $\forall x.\,P(x) \to Q(x)$. It is to avoid the confusing clutter of quantifiers and implications and the further clutter of the proof steps needed to get rid of them (intros in Rocq).

But in some cases, Isabelle itself can be the problem. Once, a student had proved some false statement and then used it to prove all the other claims (easily!). But how did he prove the false statement in the first place? Actually he didn’t: his proof was stuck in a loop. By a quirk of multithreading: when processing a theory file, If one Isabelle thread gets bogged down, other threads will still race ahead under the assumption that the bogged-down proof will eventually succeed. Such issues are easily identified if you run your theory in batch mode: it would simply time out. I have given an example of this error in another post. Experienced users know to be wary when proofs go through too easily.

Another way to prove nonsense is getting your definitions wrong. With luck, the lemmas that you have to prove about your definitions will reveal any errors. Apart from that, you will be okay provided the definitions do not appear in the main theorem. Recently I completed a large proof where I was deeply unsure that I understood the subject matter. Fortunately, the headline result included none of the intricate definitions involved in the work. The key point is that making a definition in a proof assistant does not compromise its consistency. If the definition is wrong, theorems mentioning it will not mean what you think they mean, but you will not be able to prove $1=0$.

This is also the answer to those who complain that $x/0=0$ in Isabelle (also, in HOL and Lean): if your theorem does not mention¹ the division symbol then it doesn’t matter. And if it does mention division, then the only possible discrepancy between Isabelle’s interpretation and the traditional one involves division by zero; in that case, there is no traditional interpretation to disagree with.

Soundness bugs in proof assistants

We expect proof assistants to be correct, but how trustworthy are they really? I spent a little time tracking down soundness errors in a few of them: first, naturally, Isabelle, where there has been one error every 10 years.

In 2025 (last February), somebody showed how to prove false in Isabelle/HOL using normalisation by evaluation, which bypasses the proof kernel. This was not a kernel bug, and unlikely to bump into by accident, but it was obviously unacceptable and was fixed in the following Isabelle release.

In 2015, Ondřej Kunčar found a bug in Isabelle/HOL’s treatment of overloaded definitions. A particularly cunning circular definition was accepted and could be used to prove false. I recall arguing that this was not really a soundness bug. But just above, I have noted how important it is that definitions preserve consistency: in particular, that they can be eliminated (in principle) by substitution. Kunčar and Popescu put a great effort into not just fixing this bug but putting the definition mechanism onto a sound theoretical bases.

In 2005, Obua discovered that essentially no checks were being performed on overloaded definitions. He discovered a not-quite-so cunning circular definition that could be used to prove false (details in the previous paper).

There must have been earlier soundness bugs in Isabelle, but I cannot remember any beyond those above. Definitions were not being checked for circularity because Isabelle was specialised research software and I couldn’t be bothered to stop people from hanging themselves: that old UNIX spirit. But good computer systems do protect users.

An early soundness bug in HOL88 also involved definitions. It was omitting to check that all the variables on the right hand side of the definition also appeared on the left-hand side. That leads to a contradiction trivially. A subtler error is to allow a definition where the right hand side is “more polymorphic” than the left and depends on some property of a type.

I can still remember a soundness bug that I introduced into LCF 40 years ago. I was coding 𝛼-conversion: a function to test whether two λ-expressions were equivalent up to renaming of bound variables. For example, $\lambda x.x$ and $\lambda y.y$ are 𝛼-equivalent. But I was coding in LISP and used a popular optimisation of testing for pointer equality, overlooking that it made no sense here. My code regarded $\lambda x.x$ and $\lambda y.x$ as equivalent. This sort of bug is particularly dangerous because it is in the kernel.

I have never heard of any soundness bug in Rocq, but fortunately, the Rocq team maintain a convenient list of critical bugs. It’s scary, and you have to wonder what they did wrong. After all, Lean is based on a similar calculus and seems to have a good soundness record. Another seriously buggy proof assistant is PVS; at least, it was 30 years ago. PVS has no proof kernel.

My impression is that the LCF style systems, including the HOL family as well as Isabelle, have an excellent record for soundness, confirming Robin Milner’s conception from half a century ago – and with no countervailing penalty.

So can we rely on machine proofs?

Of the woeful tales related above, I am not aware of any that had practical implications. Even soundness bugs seem to have a limited impact. Griffioen and Huisman wrote of PVS

The obvious question thus arises, why use a proof tool that probably contains soundness bugs? … PVS is still a very critical reader of proofs.

A close examination of almost any proof published in a mathematics journal will identify errors. Most are easy to fix, but the persistence of errors must undermine our confidence in published mathematics. Let’s recall once again that remarkable group of footnotes from The Axiom of Choice, by T J Jech:

This exact list was used by DeMillo et al. as evidence for the strength of the mathematical community and decades later, in my own grant proposal, as evidence for its weakness. In the case of machine proofs, with the crucial caveat that abstract models of the real world often turn out to be inadequate, we do not find errors. Evidence from testing suggests that verification works.

In my corner of the world of interactive theorem proving, we take soundness seriously. Mike Gordon strongly promoted a definitional approach: no axioms ever, all proof developments built upon pure higher-logic from definitions alone, to avoid any danger of inconsistency. Many of the variants of the HOL system owe their existence to a desire for ever greater rigour. For example, John Harrison writes “HOL Light is distinguished by its clean and simple design and extremely small logical kernel.” The HOL light kernel was later verified. The apotheosis of this project is the Candle theorem prover, created by porting HOL Light to the CakeML language. Candle has been proved to correctly implement higher-order logic, and moreover, this theorem has been established for its compiled machine code. We have no way of knowing whether higher-order logic is consistent, but if it isn’t, there will be nothing left of mathematics.

Incidentally, higher-order logic is remarkably self-contained. Over past decades, the HOL provers and Isabelle/HOL have gained numerous extensions: recursive datatypes, general recursive function definitions with pattern matching, inductive definitions and coinductive definitions. These are all definable within higher order logic, whereas similar capabilities in dependent type theories always seem to require extensions to the kernel. And that means, any bugs are kernel bugs. In view of the much greater logical strength of dependent type theories, this situation is hard to understand.

directly or indirectly (see the first comment below) ↩

50 years of proof assistants

Fri, 05 Dec 2025 00:00:00 +0000

Crackpots ranging from billionaire Peter Thiel to random YouTube influencers claim that science has been stagnating for the past 50 years. They admit that computing is an exception: they don’t pretend that my personal 32GB laptop is not an advance over the 16MB mainframe that served the whole Caltech community when I was there. Instead they claim that advances in computing were driven solely by industrial research, quite overlooking the role of academia and government funding in pushing the VLSI revolution, RISC processor design, networking, hypertext, virtual memory and indeed computers themselves. As for the industrial research, most of it came from just two “blue sky” institutes – Bell Labs and Xerox PARC – that closed a long time ago. LCF-style proof assistants are a world away from mainstream computing, so let’s look at 50 years of progress there.

1975–1985: Edinburgh LCF

The first instance of LCF was Stanford LCF, developed by Robin Milner in 1972, but it was not an LCF-style proof assistant! LCF meant “Logic for Computable Functions”, a quirky formalism based on Scott domains and intended for reasoning about small functional programs. But “LCF-style proof assistant” means one that, like Edinburgh LCF, was coded in some form of the ML programming language and provided a proof kernel, encapsulated in an abstract type definition, to ensure that a theorem could only be generated by applying inference rules to axioms or other theorems:

… the ML type discipline is used… so that—whatever complex procedures are defined—all values of type thm must be theorems, as only inferences can compute such values…. This security releases us from the need to preserve whole proofs… — an important practical gain since large proofs tended to clog up the working space… [Edinburgh LCF, page IV]

Edinburgh LCF was first announced in 1975, which conveniently is exactly 50 years ago, at the almost mythical conference on Proving and Improving Programs held at Arc-et-Senans. The user manual, published in the Springer lecture notes series, came out in 1979. Edinburgh LCF introduced some other principles that people still adhere to today:

inference rules in the natural deduction style, with a dynamic set of assumptions
a goal-directed proof style, where you start with the theorem statement and work backwards
a structured system of theories to organise groups of definitions

Edinburgh LCF had its own version of the ML language. It supported a fragment of first-order logic containing the logical symbols $\forall$, $\land$ and $\to$ along with the relation symbols $\equiv$ and $\sqsubseteq$. It introduced proof tactics and also tacticals: operators for combining tactics. Tactics supported goal-directed proof, but Edinburgh LCF had no notion of the current goal or anything to help the user manage the tree of subgoals. Its user interface was simply the ML top level and the various theorem-proving primitives were simply ML functions. ML stood for metalanguage, since managing the process of proof was its exact job.

Avra Cohn and Robin Milner wrote a report on proving the correctness of a parsing algorithm using Edinburgh LCF. The proof consists of one single induction followed by a little simplification and other reasoning. The report includes a succinct description of Edinburgh LCF. It is a nice snapshot of the state of the art in 1982, when I arrived in Cambridge to join a project run by Robin Milner and Mike Gordon. Full of youthful enthusiasm, I told Mike that it would be great if one day we could formalise the Prime Number Theorem. I hardly knew what the theorem was about or how to prove it, but my college roommate had told me it was really deep.

Disappointed to discover that we only had $\forall$, $\land$ and $\to$, I set out to fix that, to support full first-order logic. I ended up changing so much (backwards compatibility is overrated) that people eventually shamed me into writing my own user manual. Cambridge LCF never caught on because, well, nobody liked the LCF formalism. But I used it for a development that seemed big at the time: to verify the unification algorithm. This development was later ported to Isabelle. It contains 36 inductions, so we were making progress. And this takes us to 1985, exactly 40 years ago; see also this survey of the state of play. But there was almost no mathematics: no negative numbers and no decimal notation, so you could not even write 2+2=4. As far as the broader computer science community was concerned, we were a joke.

1985–1995: Cambridge LCF and HOL

Cambridge LCF was in itself a dead end, but because it included a much faster ML compiler, it ended up being incorporated into a lot of other proof assistants, notably Mike’s HOL88. And just like that, hardware verification became a reality. Although software verification seemed stuck in the doldrums, a couple of production-ready chip designs were verified! Mike’s explanation was that hardware verification was simply easier.

Also in 1985, we got a new standard for the ML language and, soon, two compilers for it. So then I started working on experiments that would lead to Isabelle. It would be like LCF but would support constructive type theory, crucially allowing both unification and backtracking, like in Prolog. But there was no working system yet, just a grant application. And that was the state of play 40 years ago.

Funding secured, Isabelle development started in earnest in 1986. It was coded in Standard ML from the start, while HOL88 was ported from the Cambridge LCF version of ML to Standard ML, emerging as HOL90. Mike acquired a bevy of energetic PhD students, who engaged in verification projects or built extensions for HOL. Versions of HOL were being used in institutes around the world.

Stepping aside from HOL for a moment, other proof assistants had made great progress by the mid 1990s. The addition of inductive definitions to the calculus of constructions gave us the calculus of inductive constructions, which in essence is the formalism used today by Rocq and Lean. The very first release of Isabelle/HOL happened in 1991, primarily the work of Tobias Nipkow, though I was soon to join in. Isabelle/ZF, which was my pet project, formalised axiomatic set theory to some quite deep results.

But I am still not certain whether negative numbers were supported (can somebody help me?). Our weak support for arithmetic may seem odd when our research community was aware that the real numbers had been formalised in AUTOMATH, but we didn’t seem to want them. To many, we were still a joke. This was about to change.

1995–2005: Proof assistants come of age

In 1994, came the Pentium with its FDIV bug: a probably insignificant but detectable error in floating-point division. The subsequent product recall cost Intel nearly half a billion dollars. John Harrison, a student of Mike’s, decided to devote his PhD research to the verification of floating-point arithmetic. By June 1996 he had submitted an extraordinary thesis, Theorem Proving with the Real Numbers, which described a formidable series of achievements:

a formalisation of the real member system in HOL
formalised analysis including metric spaces, sequences and series, limits, continuity and differentiation, power series and transcendental functions, integration
proper numerals represented internally by symbolic binary, and calculations on them
computer algebra techniques including a decision procedure for real algebra
tools and techniques for floating-point verification by reference to the IEEE standard

This thesis, which I had the privilege to examine, won a Distinguished Dissertation Award and was published as a book by Springer. So by the middle of the 1990s, which was 30 years ago, we had gone from almost no arithmetic to a decent chunk of formalised real analysis that was good enough to verify actual floating-point algorithms.

This period also saw something of an arms race in automation. My earlier, Prolog-inspired vision of backtracking search had led to some fairly general automation that was effective not just in standard predicate logic but with any theorems were expressed in a form suitable for forward or backward chaining. I had also done experiments with classical automatic techniques such as model elimination, which, although pathetic compared with automatic provers of that era, was good enough to troll users on the hol-info mailing list. Soon I had provoked John Harrison to build a superior version of ME for HOL Light. Later, Joe Hurd built his metis superposition prover, which found its way into HOL4. Not to be outdone, Tobias made Isabelle’s simplifier the best in its class incorporating a number of sophisticated refinements, including some great ideas from Nqthm.

Twenty years from the start of this chronology we now had several reasonably mature and powerful systems, including Isabelle/ZF, Isabelle/HOL, multiple versions of the HOL system, and Coq (now Rocq).¹ Many of them used Proof General, a common user interface for tactic-based proof assistants based on the Emacs editor. And we had 100MHz machines, some with 64MB of memory! We were ready to do big things.

During this period, I did a lot of work on the verification of cryptographic protocols, also here. These secure Internet connections and other network communications; they are valuable when you need to know who is on the other end and need to keep messaging secure from eavesdropping and tampering. Among the protocols investigated were the ubiquitous TLS and the late, unlamented SET protocol. These proofs were not at the level of code or bits; buggy implementations could and did emerge.

In 2005, the big thing that caught everyone’s eye was George Gonthier’s formalisation (in Coq) of the Four Colour Theorem. Most educated people had heard of the theorem already, and its history is fascinating: numerous proofs had been attempted and rejected since the mid 19th century. The 1977 proof by Appel and Haken was questioned because it relied on a lot of ad-hoc computer code. Suddenly, despite the still unwelcome involvement of computers, no one could doubt the theorem anymore.

At the opposite extreme was my own formalisation of Gödel’s proof of the relative consistency of the axiom of choice in Isabelle/ZF. This was the apex of my ZF work, technically difficult but incomprehensible to most people. My early dream of having a formalisation of the Prime Number Theorem came true in 2005 when Jeremy Avigad formalised the theorem in Isabelle. Somewhat later, John Harrison formalised a different proof in HOL Light. And there was much more. Without any doubt, our systems were capable of serious mathematics.

Perhaps the most consequential achievement of this period was Mike Gordon’s collaboration with Graham Birtwistle and Anthony Fox to verify the ARM6 processor. Graham, at Leeds, formally specified the instruction set architecture of the processor (i.e. the assembly language level), while Mike and Anthony at Cambridge verified the implementation of that architecture in terms of lower level hardware components. Eventually a number of other processors were similarly specified, and some verified. Without any doubt, our systems were capable of serious verification.

Despite of the focus on applications in this section, system development continued in the run-up to 2005. I am only familiar with Isabelle development, but they were tremendous:

the Isar language for structured, legible proofs (a break with the LCF idea that the top level must be a programming language, i.e. ML)
axiomatic type classes, providing principled overloading
counterexample finders: Quickcheck and Refute (now Nitpick)
code generation from the executable fragment of higher-order logic, and reflection
sledgehammer was under active development, but only ready a couple of years later.

With so much going on, it’s not surprising that our community started doing big things, and other people were starting to notice.

2005–2015: The first landmarks

I am not used to phone calls from journalists: for most of my career, formal verification has been seen as (at best) niche. But the journalist on the end of the line was asking for information about seL4, the first operating system kernel ever to be formally verified. Tools for extended static checking were by then able to detect a lot of program faults, but the seL4 verification claimed to cover full functional correctness: the code did exactly what it was supposed to do. There is now an entire ecosystem around seL4, backed by a million lines of Isabelle/HOL proofs.

People have wanted to verify compilers since forever. The task of fully specifying a programming language, target machine and compiler already seemed impossible, let alone providing the actual proof. With CompCert, that task was finally fulfilled, for a large subset of the C language:

What sets CompCert apart from any other production compiler, is that it is formally verified, using machine- assisted mathematical proofs, to be exempt from mis- compilation issues. In other words, the executable code it produces is proved to behave exactly as specified by the semantics of the source C program.

A seemingly intractable problem with compiler verification was how to translate your verified compiler into machine code. For example, CompCert is mostly written in Rocq, which is then extracted to OCaml code. The OCaml compiler had never been verified, so how do we know that its compiled code is correct?²

CakeML squares this circle through bootstrapping. CakeML translates from its source language (a dialect of ML) to assembly language, accompanied by a proof that the two pieces of code are equivalent. This work was an outgrowth of the ARM6 project mentioned earlier. Magnus Myreen had developed techniques for automatically and verifiably translating between assembly language and recursive functions in higher-order logic, in both directions. At the start of the bootstrapping process, a tiny compiler was written in pure logic and proved correct. It was now safe to run this compiler and use its tiny language to implement a bigger language. This process ultimately produced a verified compiler in both source form and assembly language form, with a proof of their equivalence, as well as verified extraction from higher-order logic to ML.

The end of the decade also saw impressive results in the formalisation of mathematics:

Gödel second incompleteness theorem, by yours truly, in Isabelle/HOL
the Central Limit Theorem, by Avigad et al., ditto
the Flyspeck project, by Hales et al., in Isabelle/HOL and HOL Light
the odd order theorem, in Rocq

Without going into details here, each of these was an ambitious proof, combining in various ways deep mathematics, intricate technicalities and sheer bulk. Our community was proud of our achievements. We were no longer a joke, but what exactly we were good for?

2015–2025: Breaking through

This period brought something astonishing: acceptance of proof assistants by many mainstream mathematicians. I mostly recall mathematicians regardeding computers with something close to contempt. Even some logicians regarded formalised mathematics as impossible, somehow fixating on Gödel’s incompleteness or that notorious proof of 1+1=2 on page 360. Regarding my work formalising big chunks of ZF theory, someone commented “only for finite sets obviously”.

My EU-funded ALEXANDRIA project started in 2017. My team formalised more advanced and deep mathematics than I ever imagined to be possible, using Isabelle/HOL. (I have told this story in an earlier blogpost.) But ALEXANDRIA alone would not have had much of an impact on mathematical practice. What made a difference was Kevin Buzzard and his enthusiastic, tireless promotion of the idea of formalising mathematics in Lean. He recruited a veritable army. I got the idea of blogging from him, but my blog has not had the same impact. Where are you guys?

In 2022, for the first time ever, machine assistance was used to confirm brand-new mathematics that a Fields Medallist had concerns about. Mathematicians will for the most part continue to work the way they always have done, but proof assistants are getting better and better, and they will encroach more and more on the everyday practice of mathematics.

Meanwhile, Isabelle continued to be useful for verification. I was amazed to hear that that the systems group here in the Computer Lab had completed a major verification using Isabelle/HOL. The tradition is for systems people to despise verification tools for sweeping aside ugly things like overflow and floating point errors, even though they no longer do. Besides, a research tool like Isabelle is only used by its own developer and his students. Times were changing.

Isabelle is also one of the several proof assistants involved with CHERI, a large-scale project reviving the old idea of capabilities to ensure security at the hardware level. CHERI has produced numerous publications, some of which (for example this one and that one) describe very large proofs. These concern the design and implementation of novel computer architectures with fine-grained memory protection, and a design process with formal verification at its heart.

Isabelle has also contributed to the design of WebAssembly, a relatively new platform for web applications. By subjecting the WebAssembly specification to formal scrutiny, Conrad Watt was able to identify a number of issues in time for them to be fixed.

Finally, I’d like to mention this announcement (4 December 2025) by Dominic Mulligan of Amazon Web Services (AWS):

Over three years, lots of hard work, and 260,000 lines of Isabelle/HOL code later, the Nitro Isolation Engine (NIE) is finally announced alongside Graviton5.

Working with our colleagues in EC2, Annapurna, and AWS AppSec, we have been working to rearchitect the Nitro system for Graviton5+ instances around a small, trusted separation kernel. Written from scratch in Rust, we have additionally specified the behaviour of a core subset of the Nitro Isolation Engine kernel, verified that the implementation meets this specification, and additionally proved deep security properties—confidentiality and integrity—of the implementation.

I am biased, since I’ve been working with AWS on this exact project, but it’s a big deal. AWS has been using formal verification tools for a considerable time. A notable earlier accomplishment was verify tricky but efficient algorithms using HOL Light, speeding up RSA encryption by a massive factor.

2025–2035 Becoming ordinary

A couple of months ago, Apple announced new models in their iPhone range, but no crowds formed around Apple Stores. They once did: the iPhone was once regarded as revolutionary. Now, smartphones are a commodity, which is the final stage of a new technology. Formal verification is not ordinary yet. But it’s coming: more and more software will be seen as too important to develop any other way, as is already the case for hardware.

Postscript

I am well aware that there is much outstanding work adjacent to that described here, e.g. using other interactive tools, such as Nqthm and ACL2, PVS and Agda, and much else using Rocq. There have been amazing advances in the broader theorem proving world, also in model checking, SAT/SMT solving and their applications to extended static checking of software. I have related what I personally know. And remember, the point of this post is not (simply) to boast but to demonstrate the progress of our research community, so the more achievements the better. Feel free to add some in the comments!

This post does not prove anything about other fields of science, such as solid-state physics, molecular biology or mathematics. But it’s fair to assume that such fields have not been idle either. People have proved Fermat’s Last Theorem and the Poincaré conjecture, and settled more obscure questions such as the projective plane of order 10. People have located the remains of King Richard III, who died in 1485, excavating and positively identifying the body by its DNA. People have linked a piece of bloody cloth to Adolf Hitler and diagnosed that he had a specific genetic condition. The immensely complex James Webb Space Telescope was successfully deployed; it is now revealing secrets about the early Universe.

Sometimes I wonder about the motives of those who claim that science is moribund. Do they have political aims, or just unrealistic expectations? Were they expecting time travel or some sort of warp drive? People need to remember that movies are fiction.

Cool things were also done in LEGO, another type theory proof assistant, but sadly it soon fell by the wayside. And they were sued by some crazy guys from Billund. ↩
In fact, the correctness of CompCert is delicate for a number of reasons. ↩

Set theory with types

Fri, 21 Nov 2025 00:00:00 +0000

It is known that mathematics is heavily reliant on set theory, but no one can agree on what set theory is. Many people today understand that we have a choice between set theory and type theory, but they don’t know what type theory is either. Many think that type theory refers to some sort of dependent type theory, as found in Lean or Agda, while everything else is set theory. But prior to 1980 or so, “type theory” generally referred to higher-order logic and related systems. In 1973, NG de Bruijn wrote a paper called “Set Theory with Type Restrictions”. His discussion of set theory with types was intended as motivation for the AUTOMATH language, a dependent type theory. His thoughts are fascinating and pertinent today.

Set theory according to de Bruijn

De Bruijn begins “it has been believed throughout this century that set theory is the basis of all mathematics.” He specifies this as “Cantor set theory”, or Zermelo–Fraenkel (ZF). And indeed a lot of people continue to insist on this ZF foundation. Paradoxically, mathematicians (who are the ones with skin in the game) are generally the least interested in the technicalities of set theory: actual set theorists are scarce, and the questions they study seldom have a direct impact on other branches of mathematics. De Bruijn continues:

It seems, however that there is a revolt. Some people have begun to dislike the doctrine “everything is a set”, just at the moment that educational modernizers have pushed set theory even into kindergarten. It is not unthinkable that this educational innovation is one of the things that make others try to get rid of set theory’s grip for absolute power.

I was one of those who was taught a tiny bit of set theory in school, when I was something like eight years old. I don’t think it went beyond unions and intersections of two sets. They didn’t even cover Aronszajn trees. I don’t know who was behind this educational trend, but intersections and unions are useful concepts even in everyday life. Roger Needham liked to describe unrealistic expectations as “an elaborate description of the empty set”; people need to be able to understand such remarks.

De Briujn’s chief objection to ZF set theory comes from “the weird idea that everything is set”:

In our mathematical culture we have learned to keep things apart. If we have a rational number and a set of points in the Euclidean plane, we cannot even imagine what it means to form the intersection. The idea that both might have been coded in ZF with a coding so crazy that the intersection is not empty seems to be ridiculous.¹

He also mentions the possibility of writing $x\in x$, which seems nonsensical and gave us Russell’s paradox. Also objectionable to many are the numerous coding tricks employed, where the ordered pair $(x,y)$ becomes $\{\{x\},\{x,y\}\}$ and the natural number $n$ becomes $\{0, \ldots, n-1\}$. He continues:

The natural, intuitive way to think of a set, is to collect things that belong to a class or type given beforehand. In this way one can try to get theories that stay quite close to their interpretations, that exclude $x\in x$ and are yet rich enough for everyday mathematics.

I like this statement, because it is precisely how sets are used in Isabelle/HOL and how they could be used (but seldom are) in the HOL family of proof assistants.

I have my own objection to Zermelo–Fraenkel set theory: it is much, much too large for any imaginable purpose. It bugs me that people are continuing to grasp for even stronger systems, notably Tarski–Grothendieck set theory. Towards the end of his paper, de Bruijn says

The world where we have $\mathbb{N}$, $\mathbb{N}^\mathbb{N}$, $\mathbb{N}^{\mathbb{N}^\mathbb{N}}, \ldots$, but where [the union of all those sets] is “inaccessible”, is a world most mathematicians will doubtlessly find big enough to live in. For those who want to have a bigger world…, there is a simple way out: they just take a type SET and provide it with Zermelo–Fraenkel axioms. If they want to have the picture complete, they will not find it hard to embed the types $\mathbb{N}$, $\mathbb{N}^\mathbb{N}$, $\mathbb{N}^{\mathbb{N}^\mathbb{N}}, \ldots$ into a small portion of their paradise.

The context of this remark is that AUTOMATH, by virtue of its built-in general product, allows $\mathbb{N}$, $\mathbb{N}^\mathbb{N}$, $\mathbb{N}^{\mathbb{N}^\mathbb{N}}, \ldots$ to be constructed while having no way to form their “union” because it provides no way of indexing over types. I am impressed that de Bruijn already perceived back in 1973 that such a weak system was strong enough for most mathematics. I came to this conclusion only recently, after a series of formalisation experiments using Isabelle and higher-order logic. We can easily use the convenient language of sets in higher-order logic, and we also have the option to “take a type SET and provide it with Zermelo–Fraenkel axioms”.

Sets in higher-order logic

Higher-order logic is descended from the mysterious, never-properly-formalised system of Principia Mathematica (PM). Whitehead and Russell wrote extensively about classes, which were clearly the same thing as typed sets, though PM was never explicit about what its type system actually was. Higher-order logic as formalised by Church is PM done right. A set is nothing but a boolean-valued function, exactly the same thing as a logical predicate, and the phrase “predicate sets” is fairly common in the literature of the HOL proof assistant. Nevertheless, we think about sets and predicates differently, even in the trivial case of unions and intersections. Often I have looked at an HOL Light proof and seen a prediate $Q(x)$ defined by $\exists y. P(y) \land x = f(y)$, which is simply the image under the function $f$ of a set.

Early versions of Isabelle/HOL maintained separate types for sets and predicates. At some point about 20 years ago, somebody had the idea of abolishing the distinction, presumably to avoid some duplication. This change persisted for a couple of releases before being laboriously reversed. Sets and predicates are simply not the same.

The elements of typed set theory

Typed set theory has everything that you would expect, only typed. As de Bruijn would wish, it excludes $x\in x$: you can write $x\in A$ only if the types agree. That means, if $x$ has type $\tau$ then $A$ has type $\tau\,\texttt{set}$, which is also the type of the comprehension $\{x.\,P(x)\}$ if $x$ has type $\tau$. Union, intersection and difference combine two sets of the same type in the obvious way. We have the universal set and therefore set complement because our sets are typed: we have the set of all integers, say, or of all sets of integers, but never the set of all sets. The power set operator (which denotes the set of all subsets of its argument) takes type $\tau\,\texttt{set}$ to type $(\tau\,\texttt{set})\,\texttt{set}$.

The image operator is the set-theoretic version of the “apply to all” operator that’s called map in programming languages from Standard ML to Perl, except in LISP where it’s called MAPCAR; their MAP does something weird. In Isabelle/HOL, the image of a set A under the function f is written f ` A and please accept my apologies for a syntax influenced by PM. But mathematicians write $f(A)$ for the set of all $f(x)$ for $x\in A$, treating $A$ as a set because of its capital letter, which would never do. The inverse image is written f -` A and denotes the set of all $x$ such that $f(x)\in A$. Both operators are typed in the obvious way.

This brings us to something crucial: the function space $A\to B$ and its generalisation to the indexed product, $\prod_{x\in A}\,B(x)$. The latter was called a “dependent function space” by Robert Constable but is called the “dependent product” by people who never bothered to read Constable’s papers. It has been around for more than a century due to its close association with the axiom of choice, which states that $\prod_{x\in A}\,B(x)$ is nonempty provided $B(x)$ is nonempty for all $x\in A$. In typed set theory, we often need to talk about the set of all functions that have domain $A$ and codomain $B$, and occasionally the greater precision of the indexed product is helpful. Both are trivial to define using set comprehension; in fact, $f\in A\to B$ if and only if $f(A)\subseteq B$. There is a complication concerning function extensionality, which I will not discuss here. Another complication is that the inverse image involving a function in $A\to B$ is generally expected to be a subset of $A$; the Isabelle/HOL inverse image operator does not and cannot accomplish that.

Analogously, we need the binary product space $A\times B$. Its generalisation $\sum_{x\in A}\,B(x)$, the indexed sum (Constable’s “dependent product”), is not especially important but has its uses. Both are again trivial to define using set comprehension. As in type theory, the “non-dependent” versions $A\to B$ and $A\times B$ are not even defined separately but are simply degenerate cases of the full versions when $B$ does not depend on $x$.

If $f\in A\to B$ then we may want to know whether $f$ is an injective on the set $A$ or whether it is surjective (the image $f(A)$ equals $B$). If $f$ is both then it is a bijection between the two sets. These properties also can give us an indication of the relative sizes of $A$ and $B$: if $f$ is an injection then $A$ is “smaller” than $B$ (written $A\precsim B$ or $A\prec B$ if $A$ is strictly smaller). Then we can also talk about countable sets. Exhibiting a bijection between two sets shows that they are equinumerous and is often the easiest way to show that they have the same cardinality. In the basic Isabelle/HOL library, the cardinality function for sets returns a natural number, so it is only useful for finite sets, but we can do much better if necessary.

Incorporating all of Zermelo–Fraenkel set theory

Typed set theory, as sketched above, meets de Bruijn’s desiderata. It is also simpler and more intuitive than AUTOMATH, and can express vast swathes of mathematics in a natural manner. But, for better or worse, set-theoretic notions such as transfinite ordinals and cardinals sometimes pop up in odd places. ZF set theory becomes inescapable once its very language finds its way into your theorem statement. I have already written on how to incorporate ZF set theory into higher-order logic. It is done exactly as de Bruijn suggested: by postulating a type of ZF sets and equipping it with all the ZF axioms.

A possible annoyance with this approach is ending up with two separate mathematical worlds:

the higher-order logic world, painstakingly constructed by more than 100 Isabelle/HOL theories
the vast ZF world, with only eight Isabelle/HOL theories mainly concerned with ordinal and cardinal numbers, everything else existing only as possible consequences of the ZF axioms

As I described earlier, the AFP entry ZFC_in_HOL connects the two worlds using Isabelle’s type class system. It sets up a family of embeddings from the standard Isabelle/HOL type constructors to suitable ZF analogues. ZF thereby gets things like the set of real numbers for free: we don’t have to construct it all over again. Summarising the earlier blog post, it’s done by

defining the type class embeddable of types that can be embedded into the ZF universe
defining the type class small of types that can be embedded into some ZF set

An Isabelle library defines a type class of countable types and proves many basic types to be countable or to preserve countability. These include nat (the natural numbers) and rat (the rational numbers). Moreover, countable is a subclass of small, which is a subclass of embeddable. It follows immediately that all those basic types are small. Moreover, the function space type constructor preserves smallness. To show that there is a ZF set corresponding to the Isabelle/HOL type real, we need to show that real belongs to small, which is trivial because each real number is represented by a set of functions from nat to rat.

A simpler way to get some set theory

De Bruijn objects to the principle that “everything is a set”, but it comes in handy when you are trying to define spaces. Given any two sets $A$ and $B$, you can always construct their unions and intersections, the product $A\times B$, function space $A\to B$, also the disjoint sum $A+B$, enumerations like $\{A,B\}$, the indexed sum and product and much more. This sort of flexibility comes in handy when defining the semantics of a programming language, where variables can range over a variety of types. It also comes in handy when talking about finite state machines, where different ways of combining machines require analogous ways of combining sets of machine states. If you are in a typed world like higher-order logic, you may be tempted to just use the natural numbers along with some encoding of the necessary structures. But that sucks.

The hereditarily finite sets (type hf) give us everything that ZF does, with the big exception of infinite sets. Hereditarily finite sets are finite all the way down. Finitary constructions such as integers, rationals, and obvious data structures like pairs and lists are easily represented. But we have no real numbers (only floating point) and cannot use infinite equivalence classes either. Still, hf has everything we need for modelling possible data in a programming language or state spaces in the world of finite state machines.

The set of all hereditarily finite sets is countable, and they map naturally to the natural numbers. That means, if you use type hf, you are essentially using the natural numbers, but the structural embeddings are hidden and you get to use those beloved set-theoretic constructions. And hf is definable in higher-order logic without additional axioms.

Addendum 2025-11-22: I wrote above that the technicalities of set theory seldom mattered to anybody else, and on the same day, Quanta Magazine published this article!

This remark comes from a related paper by de Bruijn: On the roles of types in mathematics ↩

"Why don't you use dependent types?"

Sun, 02 Nov 2025 00:00:00 +0000

To be fair, nobody asks me this exact question. But people have regularly asked why Isabelle dispenses with proof objects. The two questions are essentially the same, because proof objects are intrinsic to all the usual type theories. They are also completely unnecessary and a huge waste of space. As described in an earlier post, type checking in the implementation language (rather than in the logic) can ensure that only legitimate proof steps are executed. Robin Milner had this fundamental insight 50 years ago, giving us the LCF architecture with its proof kernel. But the best answer to the original question is simply this: I did use dependent types, for years.

My time with AUTOMATH

I was lucky enough to get some personal time with N G de Bruijn when he came to Caltech in 1977 to lecture about AUTOMATH. I never actually got to use this system. Back then, researchers used the nascent Internet (the ARPAnet) not to download software so much as to run software directly on the host computer, since most software was not portable. But Eindhoven University was not on the ARPAnet, and AUTOMATH was configured to run on a computer we did not have:

Until September 1973, the computer was the Electrologica X8, after that Burroughs 6700. In both cases the available multiprogranming systems required the use of ALGOL 60.

I did however read many of the research reports, including the PhD dissertation by LS Jutting, where he presents his translation of Landau’s text Grundlagen der Analysis (described last time) from German into AUTOMATH. It is no coincidence that many of my papers, from the earliest to the latest, copied the idea of formalising a text and attempting to be faithful to it, if possible line by line.

As an aside, note that while AUTOMATH was a system of dependent types, it did not embody the Curry–Howard correspondence (sometimes wrongly called the Curry–Howard–de Bruijn correspondence). That correspondence involves having a type theory strong enough to represent the predicate calculus directly in the form of types. In AUTOMATH you had to introduce the symbols and inference rules of your desired calculus in the form of axioms, much as you do with Isabelle. In short, AUTOMATH was a logical framework:

like a big restaurant that serves all sorts of food: vegetarian, kosher, or anything else the customer wants

De Bruijn did not approve of the increasingly powerful type theories being developed in the 1990s. AUTOMATH was a weak language, a form of λ-calculus including a general product construction just powerful enough to express the inference rules of a variety of formalisms and to make simple definitions, again clearly the inspiration for Isabelle. Isabelle aims to be generic, like the big AUTOMATH restaurant. Only these days everybody prefers the same cuisine, higher-order logic, so Isabelle/HOL has become dominant. Unfortunately, I last spoke to Dick (as he was known to friends) when I was putting all my effort into Isabelle/ZF. He simply loathed set theory and saw mathematics as essentially typed. He never lived to see the enormous amount of advanced mathematics that would be formalised using types in Isabelle/HOL.

I annoyed him in another way. I kept asking, AUTOMATH looks natural, but how do we know that it is right? He eventually sent me a 300 page volume entitled The Language Theory of Automath. It describes AUTOMATH’s formal properties such as strong normalisation and Church–Rosser properties, but this was not the answer I wanted at all. I got that answer for a quite different type theory.

Martin-Löf type theory

In response to kind invitations from Bengt Nordström and Kent Petersson, I paid a number of visits to Chalmers University in Gothenburg to learn about Martin-Löf type theory. I was particularly impressed by its promise of a systematic and formal approach to program synthesis. I had already encountered intuitionism through a course on the philosophy of mathematics at Stanford University, as I recall taught by Ian Hacking. The “rightness” of Martin-Löf type theory was obvious, because it directly embodied the principles of intuition truth as outlined by Heyting: for example, that a proof of $A\land B$ consists of a proof of $A$ paired with a proof of $B$.

I devoted several years of research to Martin-Löf type theory. This included a whole year of intricate hand derivations to produce a paper that I once thought would be important, and the very first version of Isabelle. Yes: Isabelle began as an implementation of Martin-Löf type theory, which is still included in the distribution even today as Isabelle/CTT. But eventually I got tired of what seemed to me a doctrinaire attitude bordering on a cult of personality around Per Martin-Löf. The sudden switch to intensional equality (everyone was expected to adopt the new approach) wrecked most of my work. Screw that.

You might ask, what about the calculus of constructions, which arose during that time and eventually gave us Rocq and Lean? (Not to mention LEGO.) To me they raised, and continue to raise, the same question I had put to de Bruijn. Gérard Huet said something like “it is nothing but function application”, which did not convince me. It’s clear that I am being fussy,¹ because thousands of people find these formalisms perfectly natural and believable. But it is also true that the calculus of constructions underwent numerous changes over the past four decades. There seem to be several optional axioms that people sometimes adopt while attempting to minimise their use, like dieters enjoying an occasional croissant.

Decisions, decisions

We can see all this as an example of the choices we make in research. People were developing new formalisms. This specific fact was the impetus for making Isabelle generic in the first place. But we have to choose whether to spend our time developing formalisms or instead to choose a fixed formalism and see how far you can push it. Both are legitimate research goals.

For example, already in 1985, Mike Gordon was using higher-order logic to verify hardware. He was not distracted by the idea that some dependent type theory might work better for n-bit words and the like. The formalism that he implemented was essentially the same as the simple theory of types outlined by Alonzo Church in 1940. He made verification history using this venerable formalism, and John Harrison later found a clever way to encode the dimension of vector types including words. Isabelle/HOL also implements Church’s simple type theory, with one extension: axiomatic type classes. Isabelle users also derive much power from the locale concept, a kind of module system that lies outside any particular logic.

During all this time, both Martin-Löf type theory and the calculus of constructions went through several stages of evolution. It’s remarkable how the Lean community, by running with a certain version of the calculus, quickly formalised a vast amount of mathematics.

Pushing higher-order logic to its limit

I felt exceptionally lucky to win funding from the European Research Council for the advanced grant ALEXANDRIA. When I applied, homotopy type theory was still all the rage, so the proposal emphasised Isabelle’s specific advantages: its automation, its huge libraries and the legibility of its proofs.

The team started work with enthusiasm. Nevertheless, I fully expected that we would hit a wall, reaching mathematical material that could not easily be formalised in higher-order logic. Too much of Isabelle’s analysis library identified topological spaces with types. Isabelle’s abstract algebra library was old and crufty. A number of my research colleagues were convinced that higher-logic was not adequate for serious mathematics. But Anthony Bordg took up the challenge, leading a subproject to formalise Grothendieck schemes.

For some reason I had a particular fear of the field extension $F[a]$, which extends the field $F$ with some $a$ postulated to be a root of some polynomial over $F$. (For example, the field of complex numbers is precisely $\mathbb{R}[i]$, where $i$ is postulated to be a root of $x^2+1=0$.) And yet an early outcome of ALEXANDRIA was a proof, by Paulo Emílio de Vilhena and Martin Baillon, that every field admits an algebraically closed extension. This was the first proof of that theorem in any proof assistant, and its proof involves an infinite series of field extensions.

We never hit any wall. As our group went on to formalise more and more advanced results, such as the Balog–Szemerédi–Gowers theorem, people stopped saying “you can’t formalise mathematics without dependent types” and switched to saying “dependent types give you nicer proofs”. But they never proved this claim.

Now that dependent type theory has attained maturity and has an excellent tool in the form of Lean, shall I go back to dependent types? I am not tempted. The only aspects of Lean that I envy are its huge community and the Blueprint tool. I hear too many complaints about Lean’s performance. I’ve heard of too many cases where dependent types played badly with intensional equality – I sat through an entire talk on this topic – or otherwise made life difficult. Quite a few people have told me that the secret of dependent types is knowing when not to use them. And so, to me, they have too much in common with Tesla’s Full Self-Driving.

Addendum: somebody commented on Hacker News that higher-order logic is too weak (in terms of proof-theoretic strength) to formalise post-WWII mathematics. This is not quite right. It is true that higher-order logic is much, much weaker than ZF set theory. But one of the most striking findings of ALEXANDRIA is that this is no obstacle to doing advanced mathematics, say to formalise Grothendieck schemes. Such elaborate towers of definitions do not seem to ascend especially high in the set-theoretic hierarchy. I can only recall a couple of proofs (this one, and that one) that required strengthening higher-order logic with the ZF axioms (which is easily done). These were theorems that referred to ZF entities in their very statements.

Especially as regards constructive mathematics. To its founders, intuitionism is a philosophy suspicious of language, which it relegates to the purpose of recording and communicating mathematical thoughts. This is the opposite of today’s “constructive mathematics”, which refers the use of a formalism satisfying certain syntactic properties. ↩

Most proofs are trivial

Wed, 15 Oct 2025 00:00:00 +0000

Perhaps I have to begin with an apology. I am not asserting that mathematics is trivial, nor am I belittling students who struggle with elementary exercises. I know how it feels to be told that a problem I cannot solve is trivial. Nevertheless, the claim of this post is on the one hand obvious and on the other hand profound. It suggests new ways of thinking about proof assistants and program verification. But first, I had better prove my point.

Discrete mathematics

Many students hate discrete mathematics and find the problems hard. Consider for example the powerset identity $\mathcal{P} (A\cap B) = \mathcal{P} (A) \cap \mathcal{P} (B)$. A typical student will ask, “how do I even begin?”. But for many of these problems there is just one thing you can do: some obvious step that doesn’t yield an immediate solution, but leads to another obvious step and another and another. This heuristic is called “following your nose” and it is a great way to prove trivial theorems. The first obvious step is that two sets are equal if they contain the same elements, so we try

\[\begin{align*} X \in \mathcal{P} (A\cap B) \iff X \subseteq A\cap B \iff X \subseteq A \land X \subseteq B \iff X \in \mathcal{P} (A) \cap \mathcal{P} (B). \end{align*}\]

Yup, it’s trivial, even if some of those steps could have been expanded out a bit more.

Many facts of discrete mathematics can be proved by following your nose. And this gives us a definition of trivial: results that follow more or less mechanically from the definitions. The fundamental theorem of arithmetic, which states that every natural number has a unique factorisation into primes, is a good example of a non-trivial result. Its proof strays far beyond the definition of a prime number, relying on Bézout’s identity, which relies on Euclid’s algorithm for computing greatest common divisors.

Whitehead and Russell’s Principia Mathematica

In this landmark work, the authors set out to prove that mathematics could be reduced to logic. And they succeeded, introducing a formal system that, after simplification, became what we know today as higher-order logic, which has recently been used to formalise truly substantial chunks of mathematics. PM is notorious for its horrible notation (take a look!), and also for taking 360 pages to prove that 1+1=2.

PM contains only trivial proofs. As I remarked in an earlier post, these assertions were used as exercises in early theorem proving experiments. Newell and Simon’s heuristic Logic Theorist proved 38 theorems from the first two chapters in 1958. Shortly afterwards, Hao Wang used his knowledge of logic to implement an algorithm that proved hundreds of theorems from PM in minutes, on a IBM 704. It is no disparagement of Wang’s work to say that he demonstrated that PM presents a list of trivial proofs. And if you don’t believe me, here is ChatGPT:

the “abridged edition” of Principia Mathematica (the one that ends at §56) does not contain any “difficult” theorems in the sense of being mathematically deep or challenging; rather, it consists entirely of extremely elementary logical and propositional results, all proved in excruciating detail.

Wang’s level of automation is utterly unattainable – even after seven decades of technological advances – for a typical mathematics textbook.

Foundations of Analysis

Edmund Landau’s textbook Grundlagen der Analysis was chosen for the first large-scale experiment with AUTOMATH because, as de Bruijn remarked, it was nicely detailed right through to the end. Landau’s book develops the complex number system from pure logic, so it can be seen as an updated version of PM without the philosophy.

Most of Landau’s proofs are trivial. He introduces the positive natural numbers axiomatically, including the usual definitions of addition, ordering and multiplication. The algebraic laws that they enjoy are important mathematical facts, but their proofs are all trivial inductions.

Next, he introduces fractions as equivalence classes of pairs of natural numbers. Equivalence classes can be a challenge, both for students and for some proof assistants. However, they are mathematically simpler than identifying rational numbers with reduced fractions, which would require a theory of greatest common divisors and tough proofs to show, for example, that addition of reduced fractions is associative. Once you are comfortable with the idea that a rational number is an equivalence class, you can obtain such facts as associativity with little fuss: they become trivial. Proofs are easier if you use the right mathematical tools, even if they require some sophistication.

Landau continues by defining Dedekind cuts of rationals, which yields the positive real numbers. Theorem 161 on the existence of square roots is one of the few nontrivial proofs in this chapter. He proceeds to develop the real and complex number systems straightforwardly. The “main theorem” of the book is Dedekind’s Fundamental Theorem, which expresses the completeness of the reals and has a detailed proof covering three pages. But Landau’s style is extremely detailed and even this proof cannot be called hard.

Landau’s obtains the real numbers from the positive reals by a signed-magnitude approach that complicates proofs with a massive explosion of cases. Equivalence classes of pairs of positive reals (representing their difference) is the elegant way to introduce zero and the negative reals. It’s hard to see why Landau made such an error.

Few modern textbooks are as detailed as Grundlagen. Authors prefer to present only the hard proofs, leaving the easy ones (the majority) as exercises. Don’t be fooled!

Cantor’s theorem

Cantor’s theorem states that, for any set $A$, there exists no surjective function $f : A \to \mathcal{P}(A)$. The proof, by Russell’s paradox, is easy and was first generated automatically way back in 1977. The Isabelle version is just a few lines of Isar text.

theorem Cantors_theorem: "∄f. f ` A = Pow A"
proof
  assume "∃f. f ` A = Pow A"
  then obtain f where f: "f ` A = Pow A" ..
  let ?X = "{a ∈ A. a ∉ f a}"
  have "?X ∈ Pow A" by blast
  then have "?X ∈ f ` A" by (simp only: f)
  then obtain x where "x ∈ A" and "f x = ?X" by blast
  then show False by blast
qed

Cantor’s theorem is profound and has wide-ranging implications. It implies that there is no universal set and no greatest cardinal number. So the theorem is not trivial, but methinks the proof kinda is.

Operational semantics of programming languages

Since the 1980s, we have had highly sophisticated techniques for specifying the semantics of programming languages, both static semantics such as type checking and name resolution, and dynamic semantics or what happens at runtime (including concurrency). Using such techniques, we can prove that a proposed programming language satisfies key properties such as progress (a well typed expression can make another step of evaluation) type preservation (such an evaluation step will not change its type), and determinacy (the next evaluation step is unique).

The techniques rely on specifying typing, reduction, etc. as relations defined inductively), as I have demonstrated in a previous blogpost. As mentioned in that blogpost, these proofs are simultaneously highly intricate and trivial:

They are intricate because simply to apply the relevant induction rule requires pages of formulas, which are almost impossible to write out correctly by hand.
They are trivial because the properties typically proved hold by design. Languages are designed such that the type system makes sense, evaluation steps don’t change integers into strings and (except for a concurrent language) there is only one possible next step. The student who has laboriously written out all the cases of an induction typically discovers that they hold immediately by contradiction or by chasing equalities.

Some program properties do have deep and difficult proofs. The quintessential example is the Church-Rosser theorem, which says that different evaluation paths for a particular λ-term cannot lead to different values. This obviously desirable property requires a long and complicated case analysis, and the first proofs were wrong.

Program verification

Operational semantics was the topic that led to this blogpost in the first place. People feel ripped off if they have to struggle to prove something obvious. And this links to that early critique of program verification by DeMillo, Lipton and Perlis, which I have commented on previously. What I did not mention was that DeMillo had himself researched program verification. He presented his work at Yale before Alan Perlis, who asked

Why does it take 20 pages to prove a program that is obviously correct?¹

After that, DeMillo turned against verification with all the zeal of a reformed alcoholic. Many program proofs are trivial for the same reason that operational semantics proofs are trivial: because you are verifying something that was designed to satisfy the very property you are proving. Algorithms can be subtle and deep, but program code almost never is. We should not abandon program proofs, but use verification tools that automate the tedious aspects. Where the code implements an algorithm, it helps to regard the algorithm and its refinement to executable code as separate verification tasks.

DeMillo et al. actually did understand that program proofs were generally trivial. Recall that for them, social processes were how mathematical results were confirmed, and they noted that program proofs were too boring to gain the attention of the mathematical community. Again we see the distinction between boring program proofs and deep proofs about algorithms, such as the fascinating Burrows–Wheeler transform.

Somehow they confused program proofs – mechanical and tedious to write out, but shallow – with genuinely deep results. In proof theory, it’s possible to show that there exist pathological theorems whose proofs are unimaginably large, hence the authors’ claim that verification would require a computer large enough to fill the observable universe. That claim is a ridiculous example of worst-case reasoning. But we do need verification tools that can cope with huge formulas.

What is the point of proving trivial facts?

One way to address this question is by drawing an analogy with safety checklists in medicine. The point of asking clinicians to work through a list of tasks they already know they have to do is that sometimes people forget: there’s plenty of evidence that these much-mocked checklists save lives. In the same way, checking that a program satisfies its claimed properties make sense because programmers make mistakes. In a formal mathematical development, the trivial proofs are the necessary lead-in to the headline results one is aiming for. Proving basic consequences of your definition is also a way to confirm that your definition is correct. Above all: not every obvious statement is true.

Donald McKenzie. Mechanising Proof: Computing, Risk, and Trust (MIT, 2001), p. 201 ↩

Everything you know is wrong

Sat, 20 Sep 2025 00:00:00 +0000

Among the few advantages of attaining the dizzy age of 70 is the ability to look back on half a century. Things were great back in 1975. The Cold War was over, thanks to the détente established by Nixon and Brezhnev. Most of the world’s population lived under Marxism, and that was not going to change. The Social Democrats ruled West Germany, and in the UK, even Rolls-Royce was a state-run enterprise. The world of fashion discovered pastels, bell bottoms, hot pants and platform shoes: the very zenith of human culture, styles that would live forever. Great progress had been made in Artificial Intelligence, thanks to a relentless focus on symbol processing as opposed to discredited, useless neural networks. Many thought that automatic theorem provers could lead the way to what we now call AGI. Also, watches did not have operating systems. People knew that clouds were real and that vaccines worked. Well, a lot can happen in 50 years.

Artificial Intelligence

AI is an extreme example of changing research trends. Already in 1961, a computer program had beat MIT students at calculus problems. By 1970, Terry Winograd’s SHRDLU demonstrated something remarkably like sentience in its use of English. The sort of wild predictions made today by AI boosters – that machines would put everybody out of work and maybe kill us all – were already being made back then. Consider the movie 2001: A Space Odyssey (released in 1968), featuring the smooth-talking but lethal HAL 9000. Director Stanley Kubrick had chosen MIT’s Marvin Minsky, possibly the world’s leading AI researcher, to be his scientific advisor. Minsky’s prediction turned out to be way off.

All AI work in that era was based on manipulating symbols. The book Perceptrons, by Minsky and Seymour Papert, had shown that neural networks could not even learn such a simple function as exclusive-or: they were worthless. The remaining debate was whether intelligence was procedural (embodied in code) or declarative (encoded in a symbolic formalism). SHRDLU was an example of procedural knowledge, a great mass of LISP code that no one knew what to do with. Declarative knowledge might be expressed in first-order logic or some other approach to knowledge representation, processed by an automatic theorem prover or other engine.

Expert systems – Intelligent Knowledge Based Systems – were attracting widespread attention by 1980. These contained declarative knowledge in the form of production rules obtained by interrogating human experts in a specific domain. For example, MYCIN could prescribe antibiotics given a description of the patient’s symptoms. It could even “explain” its decisions based on the production rules involved in the response to a query.

By the late 1980s, disenchantment with expert systems and other symbolic approaches led to an “AI Winter” that did not really end until neural networks were revived.

DPLL versus resolution theorem proving

Interest in automatic theorem proving dates back at least 1956: Logic Theorist could prove some simple statements from Whitehead and Russell’s Principia Mathematica. Philosopher Hao Wang and others were excited by the possibility of computers automating the process of mathematical proof. One outcome of such work was the DPLL procedure for propositional logic: the first SAT solver. It was quickly superseded by the resolution procedure, which worked in the richer formalism of first-order logic. By the mid 1970s, people were even getting disenchanted with resolution, but DPLL still seemed as dead as a doornail. Attempts to revive DPLL during the 1990s provoked laughter in some, but nobody is laughing now. Resolution has also grown in importance, even if nobody thinks it can do robot planning anymore. Prolog, a programming language originating in a specialised form of resolution, attracted enormous interest in the 1980s but had since fallen by the wayside.

Today, DPLL is the basis of powerful theorem provers based on SMT solvers and used for verifying software. Both SMT and resolution are used every time an Isabelle user invokes Sledgehammer.

Specialised hardware for declarative languages

The VLSI revolution that started in the 1970s coincided with the emergence of declarative languages such as Prolog and ML. People said that such languages were inefficient only because they were competing with von Neumann languages running on von Neumann hardware. But now anyone could put a computer on a chip, and a new class of computers designed for declarative languages would surely bridge the performance gap.

Some new hardware designs did emerge, such as the SKIM machine and the Transputer. The former had support for S, K, I combinator reduction right in its microcode to execute lazy functional languages fast. The latter was designed for parallel execution, to be wired together in massive grids for specialised computing tasks.

The big beast of this era was Japan’s Fifth Generation Computer Systems project. It was an attempt to leapfrog western computer technology through new approaches centred around Prolog, including special hardware. Similar programmes were launched in other countries, notably the UK’s Alvey Programme. The first ESPRIT programme was Europe’s response.

This burst of research activity was undoubtedly beneficial to computer science. Declarative languages such as Haskell emerged, which over time would exert a profound influence on programming language design. However, knowledge based systems still reached their dead end, and all attempts to create novel architectures were remorselessly crushed by the Intel steamroller. An off-the-shelf x86 processor could beat your special chip for a fraction of the cost of developing the latter.

Program verification versus correct-program synthesis

Program verification is the process of proving correctness properties of code that has already been written, identifying defects in the process. For much of my career the very idea has been heavily criticised, mostly as being infeasible¹ but also as being back-to-front. Begin with the problem specification, people said, and work backwards to code that is correct by design.

One of the foremost proponents of that approach was Edgar W Dijkstra, a dominant figure right up until his death in 2002. Already in his 1972 essay “Notes on structured programming” he set himself the task of printing a table of 1000 prime numbers, spending 11 pages refining the task “print first thousand prime numbers” to pseudocode in a language resembling Algol W. In this example he did not write his specifications in logic, but in later years his developments became increasingly formal. One of his bugbears was what he called a rabbit: an idea simply “pulled out of a hat” rather than determined by a calculation. I find it odd to be against having ideas.

A formal and rather elegant “deductive approach to program synthesis” was set forth by Zohar Manna and Richard Waldinger. They used a tableau style formalism intermingling logical formulas with code fragments and with a set of inference rules governing the translation from logic to executable code. Even more elegant and formal were the constructive type theories outlined by Per Martin-Löf. By formulating logical propositions as types, such theories guaranteed that the proof of a given statement yielded a proof object: executable code witnessing the claim. The approach required constructive logic, but the loss of classical reasoning was a small price to pay for bug-free code.

This dream could not work for a number of reasons:

Not all code has the same performance. It is easier to write the code you want and prove it afterwards than to prove a theorem in the precise way that would generate the code you already knew you wanted.
Specifications are seldom stable or complete. We know how to extend a program proof to cover additional properties, but we don’t have a deductive synthesis approach that is open to adding further properties later.
Many proof objects are computationally irrelevant, but you are confined to constructive reasoning even for those.

For the first point, to synthesise a sorting function we have to prove that every sequence of integers can be permuted into non-decreasing order. There is a simple proof by induction: swap the smallest element of the sequence with the first element, and since the remaining sequence is shorter by one, the conclusion follows. The corresponding algorithm is selection sort, which is no good: it takes quadratic time. To write a proof that corresponds to quicksort, you have to know quicksort already. Even in Dijkstra’s 1972 essay, he begins by remarking that the most efficient way to generate prime numbers is the Sieve of Eratosthenes and concludes by noting that he has derived exactly that.

Related to correct-program synthesis was the field of program transformations, explored by Richard Bird among others. The original specification would be executable (typically written in a functional language) but inefficient. Your task would be to transform this initial program into usable code. Lots of fascinating research went into program transformations, but this never looked like an approach that could scale to thousands of lines. If we consider sorting again, an executable specification is easily expressed in Prolog:

sort(X, Y) :- permutation(X,Y), ordered(Y).

This code enumerates every permutation Y of the input X and terminates if Y is ordered, otherwise backtracking to get another permutation. (It would be harder to code in a functional language.) This “specification” is incomplete because it assumes that such a permutation exists, which actually must be proved.

I am one of the many people who were attracted to type theory by the dream of deductive program synthesis in the early 1980s. Every so often, some researcher would attempt to execute the proof object they had derived from some interesting theorem. In almost every case, their extracted code turned out to be all but unusable. When I checked Wikipedia today, their entry on Program Synthesis mentioned the work of Manna and Waldinger but did not contain a single mention of the words “type” or “constructive”. Dang.

Postscript

If there is a lesson here, it is that almost nothing is settled for certain. What now is dead may be restored to life, what now seems invincible may be laid low, a decade or two from now.

I wish I could say that I had taken my own advice, ignored the herd and struck out boldly on my own. In fact, I pursued topics that other people found important. I even found myself bounced into joining a Prolog-oriented grant proposal for Alvey that made absolutely no sense. I devoted years to writing derivations in Martin-Löf type theory and even coding an implementation before falling out with the community’s cultish practices. The implementation became Isabelle.

A more impressive role model for a young researcher today would be Mike Gordon. He decided that he wanted to verify hardware, something no one else was interested in. After years of persistent research, he fixed on higher-order logic as the best formalism. He was not tempted by the still evolving dependent type theories, nor concerned when I mentioned that higher-order logic was distained by logicians for its messy metatheory. Already by 1986 he had achieved his initial milestone of verifying a simple but realistic computer, after which there was no stopping him.

My dictionary actually illustrates the definition of infeasible with the sentence “proof that a program works is infeasible unless it is very short”. ↩

Program verification is not all-or-nothing

Fri, 05 Sep 2025 00:00:00 +0000

There seems to be a common belief that program verification is a task that you toil at for ages until one day you see that magic word, VERIFIED. One seminar speaker made this more explicit, presenting testing as a process where you gain knowledge over time (illustrated by a graph gently curving upwards) and verification as a process where you know nothing until the end, when you know everything (illustrated by a graph flatlining until the hoped-for triumph). Where did people get this dumb idea?

All-or-nothing things

Some things really are all-or-nothing. If you attempt to climb Mount Everest and give up a short distance from the summit, you didn’t make it: all those brutal weeks of high-altitude climbing, all that danger and hardship, for nothing. Despite having performed a truly stupendous feat, you may not want to talk about how you got only 99% of the way, especially if other people climbed past you and summited.

A similar attitude prevails in mathematics. Consider Fermat’s Last Theorem: Andrew Wiles announced his proof in June 1993, but by September a serious error had been found. As of that moment, he had not proved Fermat’s Last Theorem, and all the mathematical techniques he had developed to come within 99% of that summit were seemingly as nothing, such is human psychology. Luckily, a year later, he found a way around the problem and was finally credited — along with Richard Taylor — with proving this centuries-old conjecture.

The problem in both cases is that the goal is clear and has a name: Mount Everest; Fermat’s Last Theorem. You have to actually stand on the summit; you have to prove the theorem without exceptions or doubts. This also applies to the verification of an algorithm, which is also a mathematical entity. The verification of an algorithm may be deep and difficult, but it is fundamentally a problem in mathematics.

Program verification is different

Program verification is different because even the simplest computational task has a messy specification once we consider real-world constraints. Suppose our task is to sort an array of records. Few things are simpler than sorting, yet already we have several correctness properties:

the output should be a permutation of the input
the output should be in order
optionally, the sort should be stable

Those are just the abstract mathematical requirements for sorting, but in any real world situation there will also be performance requirements about the space and time used. These might be expressed asymptotically, as $O(n\ln n)$, but there could also be real-time constraints.

Now imagine verifying some sorting code. The three abstract properties are certainly within the scope of verification, and if you prove them one at a time, your knowledge is indeed growing as you finish each claim. Techniques have long existed even for proving resource bounds for your code. Real-time constraints are another matter.

A few real-world case studies

Most verification tasks are open-ended because software systems are vastly more complicated than sorting, and people are always coming up with new new features and new properties to prove of those features. And that is before we even consider any real-world aspects to the specification. Here are a few examples:

the Gordon computer and the VIPER microprocessor
various cryptographic protocols, such as TLS
the seL4 operating system kernel

Each of these verification projects consisted of milestones that could be proved one at a time, our knowledge growing at each step. None can be called 100% complete. In the case of VIPER, Avra Cohn felt the need to point out the limitations of her proof, which she felt was being oversold. The design had not been verified down to its lowest level and the initialisation phase not at all. In the case of cryptographic protocols, essentially all verification work regards the actual cryptographic primitives as abstract and perfect; real-world TLS has numerous vulnerabilities. As for seL4, the project page helpfully lists the underlying assumptions: “assembly code, boot code, machine interface, hardware, and DMA”.

Things like assembly code and boot code are in principle verifiable; the only question is the cost. But in none of these examples is there a summit that could be attained, even with unlimited effort. For VIPER, we could verify the design right down to the bottom, but the hardware model assumes digital behaviour for what is actually silicon, saying nothing about problems that could arise due to gate delays, overheating or other low-level design errors. For the same reason, the hardware component of seL4 can never be verified 100%. Any formal model of hardware could be refined to a more accurate and detailed model until you get right down to particle physics, which itself is only a model of reality. For cryptographic protocols, we simply do not know how to show that specific encryption methods are unbreakable.

Let’s start climbing Everest

With real-world program verification, we need to be clear about what to prove and what to assume.

We can prove that our sorting code delivers a sorted permutation of its input and rely on testing to validate its real-time performance.
With cryptographic protocols, the main high-level concern is intricate replay attacks, which today’s abstract models handle well; implementers still must be careful to choose cryptographic primitives known to be secure.
A component like seL4 will be tested anyway as it is integrated into a larger system. Bugs are not found in the verified sections.

I hope I don’t need to point out that testing alone is inadequate. It’s not that long ago that computer crashes were an almost daily occurrence. Things are better now because of automated verification tools. Even the mighty Microsoft could not achieve stability through testing alone.

But testing will always have a role to play. The real world will have to be approximated by some sort of mathematical model. In the case of verified code, the purpose of testing is to test the model itself. Increasingly we shall be running verified code on verified hardware designs while only having to worry about cosmic rays, low-level attacks and other phenomena that we cannot model or predict. We won’t be at the summit of Mount Everest, but we’ll still be pretty damn high.

Definite integrals, II: improper integrals

Thu, 21 Aug 2025 00:00:00 +0000

Last time, we worked out a couple of definite integrals involving discontinuities at the endpoints. They were easy because the antiderivatives were continuous. Let’s make things harder by looking at (apparent) discontinuities and infinite endpoints, both of which require limit reasoning. We begin by taking a look at the mysteries of the extended real numbers and Lebesgue integration.

Lebesgue integration; the extended real numbers

The Isabelle/HOL analysis library provides two forms of integration:

The Henstock–Kurzweil or gauge integral
The Lebesgue integral

Although technically messy, the gauge integral can handle a strict superset of the Lebesgue integrable functions. However, Lebesgue integration, with its associated measure theory and probability theory, is the elegant foundation upon which much of analysis has been built. For Isabelle/HOL users, the overlap may be confusing, and I think it’s ugly to use both kinds of integral in a single proof. It’s best not to worry about such trivia. For difficult improper integrals, Lebesgue is the way to go: everything you are likely to need is already in the library.

Many of the key lemmas refer to the extended real numbers. These are the real numbers extended with $\infty$ and $-\infty$: symbols giving us a convenient way to express, for example, an integral over an unbounded interval. The extended reals have type ereal, which is also the name of the function that embeds real numbers into the extended reals.

It’s important to stress the extended reals do not give any meaningful treatment of infinity, such as we get with the non-standard reals. The latter is a field and algebraic facts like $x+y - x = y$ hold even for infinite and infinitesimal quantities. With the extended reals, $\infty+1 - \infty = \infty - \infty = 0$. All we get (and want) from the extended reals are two tokens $\infty$ and $-\infty$ satisfying the obvious ordering relations. Then we can express various kinds of infinite intervals just by giving the lower and upper bounds, such as $(-\infty,0]$ or $(1,\infty)$ or $(-\infty,\infty)$.

Redoing the baby example

We actually saw this example in the previous post:

\[\begin{equation*} \int_{-1}^1 \frac{1}{\sqrt{1-x^2}}\, dx = \pi \end{equation*}.\]

The first time I did this, I obtained the antiderivative through WolframAlpha as

\[\begin{equation*}\displaystyle \tan^{-1} \Bigl({\frac{x}{\sqrt{1-x^2}}}\Bigr) \end{equation*}.\]

This is the same as $\sin^{-1}(x)$ except for the division by zero at the endpoints. Moreover, it converges continuously to $\pi/2$ as $x$ tends to $1$ and to $-\pi/2$ as $x$ tends to $-1$: in other words, the singularities are removable.

Because the solution using $\sin^{-1}$ is so simple, my first plan was to abandon this example, but in every simple alternative I looked at, the removable singularity had already been removed by others: for example, $\sin x/x$ is called the sinc function. And yet, in harder problems, you may have to tackle removable singularities yourself.

So here is how we deal with this one. To begin, we need a lemma to replace $x^2>1$ by the disjunction $x<{-1}$ or $x>1$. (The library already includes the analogous lemma for $x^2=1$.)

lemma power2_gt_1_iff: "x⇧² > 1 ⟷ x < (-1 :: 'a :: linordered_idom) ∨ x > 1"
  using power2_ge_1_iff [of x] power2_eq_1_iff [of x] by auto

Now we set up the proof, with two separate theorem statements. (With the gauge integral, the has_integral relation expresses both that the integral is defined and its value.)

lemma "set_integrable lborel {-1<..<1} (λx. 1 / sqrt (1-x⇧²))"
      "(LBINT x=-1..1. 1 / sqrt (1-x⇧²)) = pi"
proof -

We make three lemmas available to the simplifier (including the one proved above), and define f to abbreviate the antiderivative.

  note one_ereal_def [simp] power2_eq_1_iff [simp] power2_gt_1_iff [simp]
  define f where "f ≡ λx. arctan (x / sqrt(1-x⇧²))"

Next, we formally verify the antiderivative by taking its derivative again. Recall that this is an appeal to the fundamental theorem of calculus (FTC). We use a variation on the differentiation technique described last time, showing that the extracted derivative equals $\frac{1}{\sqrt{1-x^2}}$.

  have "(f has_real_derivative 1 / sqrt (1-x⇧²)) (at x)"
    if "-1 < x" "x < 1" for x
    unfolding f_def 
    apply (rule refl derivative_eq_intros | use that in force)+
    apply (simp add: power2_eq_square divide_simps)
    done

Setting aside this result using moreover, we prove continuity of the integrand on the open interval $(-1,1)$. (We shall deal with the endpoints later.) As mentioned last time, proving continuity is trivial with the help of the theorem list continuous_intros. The final call to auto is to prove that the divisor is nonzero.

  moreover
  have "isCont (λx. 1 / sqrt (1-x⇧²)) x"
    if "-1 < x" "x < 1" for x
    using that by (intro continuous_intros) auto

The next step is trivial but vital. The version of the FTC I’m using requires the integrand to be nonnegative. In a moment, we’ll look at another example where it isn’t.

  moreover
  have "0 ≤ 1 / sqrt (1-x⇧²)"
    if "-1 < x" "x < 1" for x
    using that by (auto simp: square_le_1)

Our version of the FTC deals with discontinuity at the endpoints using limits. The theorem refers to the extended reals throughout, which I’ve managed to conceal so far: Isabelle can usually mediate between the reals and the extended reals. They become explicit here. The actual limit reasoning is done by the real_asymp proof method, demonstrated in a previous post.

  moreover
  have "(f ⤏ - pi/2) (at_right (- 1))"  "(f ⤏ pi/2) (at_left 1)"
    unfolding f_def by real_asymp+
  then have "((f ∘ real_of_ereal) ⤏ - pi/2) (at_right (- 1))"
            "((f ∘ real_of_ereal) ⤏ pi/2) (at_left 1)"
    by (simp_all add: ereal_tendsto_simps1)

Now we can conclude the proof. The keyword ultimately brings in all of the facts that had been set aside using moreover, and we insert a specific instance of the FTC, interval_integral_FTC_nonneg, instantiated with the relevant parameters. This works because in the previous steps we proved all of its pre-conditions.

  ultimately show 
    "set_integrable lborel {-1<..<1} (λx. 1 / sqrt (1-x⇧²))"
    "(LBINT x=-1..1. 1 / sqrt (1-x⇧²)) = pi"
    using interval_integral_FTC_nonneg [of "-1" 1 f "λx. 1 / sqrt (1-x⇧²)" "-pi/2" "pi/2"]
    by auto
qed

Integration over the entire real line

Our next example is properly improper, because the endpoints are infinite.

\[\begin{equation*} \int_{-\infty}^\infty \frac{1}{t^2+1}\, dt = \pi \end{equation*}\]

Here is its graph. Once again we have a non-negative integrand.

Maple tells us that the antiderivative is $\tan^{-1}t$. (I have also used Maple for all these graphs.)

Once again, Lebesgue integration is the way to go, since the necessary machinery has not been set up for gauge integrals. The formal proof has the same structure as in the previous example. We verify the antiderivative, show continuity of the integrand and also show the integrand to be nonnegative. Finally, we apply the FTC to obtain the two conclusions.

lemma
  defines "f' ≡ λt. 1 / (t⇧²+1)"
  shows
    "set_integrable lborel (einterval (-∞) ∞) f'"
    "(LBINT t=-∞..∞. f' t) = pi"
proof -
  have "(arctan has_real_derivative f' t) (at t)" for t
    unfolding f'_def 
    by (rule derivative_eq_intros | force simp: divide_simps)+
  moreover
  have "isCont f' x" for x
    unfolding f'_def
    by (intro continuous_intros) (auto simp: add_nonneg_eq_0_iff) 
  moreover
  have "((arctan ∘ real_of_ereal) ⤏ -pi/2) (at_right (-∞))"
       "((arctan ∘ real_of_ereal) ⤏ pi/2) (at_left ∞)"
    by (simp add: ereal_tendsto_simps1, real_asymp)+
  ultimately show "set_integrable lborel (einterval (-∞) ∞) f'"
    "interval_lebesgue_integral lborel (-∞) ∞ f' = pi"
    using interval_integral_FTC_nonneg [of "-∞" ∞ arctan]
    by (auto simp: f'_def)
qed

There are a couple of differences from the previous proof. We do not need an abbreviation for the antiderivative because it is simply arctan. But this proof features a local definition of the integrand as f', and we could have done something similar last time.

Integration of a sign-changing function

If you are unsure why a sign-changing function needs a different version of the FTC, consider that $\cos$ is both differentiable and continuous. Without the non-negative condition, the FTC would tell us that $\cos$ could be integrated over the whole real line, which is ridiculous.

And so our final example is to integrate a damped sinusoid over the non-negative real numbers.

\[\begin{equation*} \int_0^\infty e^{-t}\cos t\, dt = \frac{1}{2} \end{equation*}\]

Here is the graph. It’s hard to see, but this function crosses the $x$-axis infinitely often.

Because its sign changes, the integration proof involves two steps:

Show that the integral exists. Since $\lvert e^{-t}\cos t\rvert \le e^{-t}$, we need to show that the latter function is integrable. It is non-negative, so we apply the previous version of the FTC.
We apply a signed version of the FTC to verify what the value of the integral actually is.

Let’s do the formal proof. We start with the theorem statement, including as before a local definition of the integrand.

lemma
  defines "f' ≡ λt. exp(-t) * cos(t)"
  shows  "set_integrable lborel (einterval 0 ∞) f'"
         "(LBINT t=0..∞. f' t) = 1/2"
proof -

The first result

Concerning step 1 above, we show that $e^{-t}$ is integrable. The proof relies on the FTC for non-negative functions, just as we’ve already. Our task this time is slightly simpler because we don’t care what the integral actually is. (It’s 1.) We can therefore ignore the second conclusion of interval_integral_FTC_nonneg and write the proof as follows:

  have "set_integrable lborel (einterval 0 ∞) (λt. exp(-t))"
  proof (rule interval_integral_FTC_nonneg)
    show "((λt. -exp(-t)) has_real_derivative exp(-t)) (at t)" for t
      by (rule derivative_eq_intros | force simp: field_simps)+
    have "(((λt. -exp (-t)) ∘ real_of_ereal) ⤏ -1) (at_right (ereal 0))"
      by (simp add: ereal_tendsto_simps1, real_asymp)
    then show "(((λt. -exp (-t)) ∘ real_of_ereal) ⤏ -1) (at_right 0)"
      by (simp add: zero_ereal_def)
    show "(((λt. - exp (- t)) ∘ real_of_ereal) ⤏ 0) (at_left ∞)"
      by (simp add: ereal_tendsto_simps1, real_asymp)
  qed auto

Setting this fact aside, we prove a necessary technical condition: that the integrand is a measurable function on the closed interval $[0,\infty]$.

  moreover have "set_borel_measurable lborel (einterval 0 ∞) f'"
    using borel_measurable_continuous_on_indicator 
    by (simp add: f'_def set_borel_measurable_def)

We store this fact as well, and then prove that the integrand is absolutely bounded by $e^{-t}$.

  moreover have "⋀t. ¦f' t¦ ≤ exp(-t)"
    by (simp add: f'_def abs_mult)

Combining the facts proved above, we find that f' is indeed integrable over $[0,\infty]$. This is the first conclusion of the theorem, but we also label it because it’s needed to prove the second conclusion.

  ultimately show *: "set_integrable lborel (einterval 0 ∞) f'"
    by (metis (mono_tags, lifting) abs_exp_cancel always_eventually
        real_norm_def set_integrable_bound set_integrable_bound)

The second result

Now we turn to step 2. We insert a local definition of the antiderivative, which happens to be $e^{-t}\frac{\sin t - \cos t}{2}$. To prove the second conclusion, we express the integral as the difference between two values at the endpoints and apply the more general version of the FTC.

  define f where "f ≡ λt::real. exp(-t) * (sin(t) - cos(t)) / 2"
  have "(LBINT t=0..∞. f' t) = 0 - (- 1/2)"
  proof (intro interval_integral_FTC_integrable)

The next steps should be familiar by now. For an arbitrary real number t, we verify the antiderivative by differentiation and prove the integrand to be continuous.

    fix t
    show "(f has_vector_derivative f' t) (at t)"
      unfolding f_def f'_def has_real_derivative_iff_has_vector_derivative [symmetric]
      by (rule derivative_eq_intros | force simp: field_simps)+
    show "isCont f' t"
      unfolding f'_def by (intro continuous_intros)

The FTC requires us to verify the values attained by the antiderivative at the endpoints. Which we do using the techniques we’ve seen before, in particular, a couple of awkward tricks needed because everything has to be proved in terms of the extended real numbers.

  next
    have "((f ∘ real_of_ereal) ⤏ -1/2) (at_right (ereal 0))"
      by (simp add: ereal_tendsto_simps1 f_def, real_asymp)
    then show "((f ∘ real_of_ereal) ⤏ -1/2) (at_right 0)"
      by (simp add: zero_ereal_def)
    show "((f ∘ real_of_ereal) ⤏ 0) (at_left ∞)"
      by (simp add: ereal_tendsto_simps1 f_def, real_asymp)

Now auto (given the first result, namely *) wraps up the proof.

  qed (use * in auto)
  then show "(LBINT t=0..∞. f' t) = 1/2"
    by simp
qed

A few concluding remarks

As we have seen, an Isabelle theorem declaration can have multiple conclusions. In the case of interval_integral_FTC_nonneg, it makes sense because both conclusions depend on the same premises and much of the same reasoning. In the last example, I did this simply for the sake of uniformity. In the case of gauge integrals, Isabelle provides has_integral to express that the integral exists and has the given value. Somewhat similarly, has_bochner_integral refers to Lebesgue integrals, but it is a bit clunky for integrating over the real line.

The Isabelle theory file formalising the examples in this and the previous post are online.

Definite integrals, I: easy cases over finite intervals

Thu, 14 Aug 2025 00:00:00 +0000

On occasion, your Isabelle proof may require you to work with a definite integral. (That is, the area under a curve between two points on the x-axis.) In the simplest case, all we have to do is integrate the given function to obtain its antiderivative, which we then evaluate at the endpoints, returning the difference. But things are not always simple. There could be discontinuities in the integrand (the function being integrated) or in its antiderivative. Either or both of the endpoints could be infinite. And while we say “area under a curve”, our notion of area is in fact signed, going negative when the curve crosses the x-axis. Finally, Isabelle has no actual capability to take integrals. Let’s work through a few examples in which we symbolically evaluate a definite integral, proving that the result is correct.

A baby example

Let’s begin with the following integral:

\[\begin{equation*} \int_{-1}^1 \frac{1}{\sqrt{1-x^2}}\, dx = \pi \end{equation*}\]

Here is a graph of the integrand. It goes to infinity at both endpoints. Still, the integral is defined.

The antiderivative is $\sin^{-1}$, the inverse sine function, which is continuous. The integral is $\sin^{-1}(1) - \sin^{-1}(-1) = \frac{\pi}{2} - (-\frac{\pi}{2}) = \pi$.

To do this in Isabelle, our first task is to carry out the integration. Isabelle has no such capability, but that doesn’t matter: Isabelle can differentiate, so we simply use some external tool to integrate, confirming its answer by formally proving that its derivative matches the original integrand. This is an appeal to the Fundamental Theorem of Calculus (FTC), which says that integration and differentiation are inverse operations of each other. The Isabelle libraries provide numerous variants of this fact.

As for the external tool: WolframAlpha, which is free, can often do the job, but here I needed Maple to find out that the antiderivative was simply the inverse sine.

The Isabelle proof is so simple, there is almost nothing to say. The key point is the form of the FTC chosen: fundamental_theorem_of_calculus_interior, which allows the integrand to diverge at the endpoints provided the antiderivative is continuous over the full closed interval.

lemma "((λx. 1 / sqrt(1-x⇧²)) has_integral pi) {-1..1}"
proof -
  have "(arcsin has_real_derivative 1 / sqrt (1-x⇧²)) (at x)"
    if "- 1 < x" "x < 1" for x 
    by (rule refl derivative_eq_intros | use that in ‹simp add: divide_simps›)+
  then show ?thesis
    using fundamental_theorem_of_calculus_interior [OF _ continuous_on_arcsin']
    by (auto simp: has_real_derivative_iff_has_vector_derivative)
qed

The proof begins by showing that the derivative of $\sin^{-1}$ is indeed $\frac{1}{\sqrt{1-x^2}}$, though only on the open interval $({-1},1)$. This fact, along with the continuity of $\sin^{-1}$, is supplied to the FTC, which sets up the calculation of $\sin^{-1}(1) - \sin^{-1}(-1)$.

A just slightly harder example

This next example, $\int_0^1 \frac{1}{\sqrt{x}}\, dx = 2$, presents the same difficulty: divergence at an endpoint.

Mathematically, its treatment is identical to the previous example. The integrand diverges at zero. Its antiderivative is $2\sqrt{x}$, which fortunately is continuous for all $x\ge0$.

As for the formal proof, we use a little Isar to introduce the abbreviation f for the antiderivative, which is referred to a number of times. We prove that f is continuous over the closed interval and verify that it has the correct derivative over the open interval, avoiding the discontinuity at zero.

lemma "((λx. 1 / sqrt x) has_integral 2) {0..1}"
proof -
  define f where "f ≡ λx. 2 * sqrt x"
  have "(f has_real_derivative 1 / sqrt x) (at x)"
    if "0 < x" "x < 1" for x
    unfolding f_def
    by (rule refl derivative_eq_intros | use that in ‹simp add: divide_simps›)+
  moreover
  have "continuous_on {0..1} f"
    by (simp add: continuous_on_mult continuous_on_real_sqrt f_def)
  ultimately
  have "((λx. 1 / sqrt x) has_integral (f 1 - f 0)) {0..1}"
    by (intro fundamental_theorem_of_calculus_interior)
       (auto simp: has_real_derivative_iff_has_vector_derivative)
  then show ?thesis 
    by (auto simp: f_def)
qed

If the integrand is differentiable over the closed interval, then the proof can be done using fundamental_theorem_of_calculus, a version of the FTC that does not require a separate proof of continuity.

Taking derivatives in Isabelle

It’s easy to take the derivative of a function or to prove that it is continuous. Isabelle does not provide dedicated proof methods for such tasks, relying instead on its own Prolog-like proof engine. Above we used the following line, although variations are possible:

    by (rule refl derivative_eq_intros | use that in ‹simp add: divide_simps›)+

Key is the theorem list derivative_eq_intros, which as of today has more than 140 entries. A typical one says in essence that to show that the derivative of $\lambda x. f (x) + g(x)$ is $h$, show the following:

that the derivative of $f$ is some $f’$,
that the derivative of $g$ is some $g’$,
that $(\lambda x. f’ (x) + g’(x)) = h$.

The point is that both $f’$ and $g’$ will be logical variables (in the Prolog sense), so the repetitive application of derivative_eq_intros can calculate the derivatives of the subterms into them. We alternate with simplifier calls because the result of the raw process produces terms like $0\cdot x^1 + 1\cdot x^0$. But if the simplifier alters the outer form of the equations, say by moving a term across the equals sign, then the process probably won’t work. A little tinkering is sometimes necessary.

To prove that a function is continuous, use the theorem list continuous_intros. The idea is similar to differentiation: in fact a lot simpler, because there is nothing to calculate. Therefore there is no need to call the simplifier. We shall see several continuity proofs in the forthcoming Part II.