Hacker News new | past | comments | ask | show | jobs | submit login
Why is dependent type theory more suitable than set theory for proof assistants? (mathoverflow.net)
221 points by pgustafs 11 days ago | hide | past | favorite | 59 comments





The current tittle of the original MathOverflow question is "What makes dependent type theory more suitable than set theory for proof assistants?", I don't know why is it different than here. The actual question makes more sense because the one on HN suggests that proof assistants exclusively formalize mathematics in dependent type theory (rather than set theory) which is not true. In fact, some proof assistants use dependent type theory (LEAN), some use simple type theory (Isabelle/HOL), some use simple type theory to encode untyped set theory (Isabelle/ZF), some implement kind of "soft typing" on top of untyped set theory (Mizar) and some are completely generic and can encode all of the above (Metamath). As for the question why type theory seems to be more popular in formalization of mathematics recently than set theory Jeremy Avigad wrote a rare compelling explanation [1] of why this is the case. I personally prefer the opinion of Lawrence Paulson [2], the original author of Isabelle and its ZF logic (he also implemented a formalization of ZFC set theory in Isabelle/HOL recently).

[1] https://cs.nyu.edu/pipermail/fom/2016-January/019441.html

[2] https://cs.nyu.edu/pipermail/fom/2018-June/021032.html


> The current tittle of the original MathOverflow question is "What makes dependent type theory more suitable than set theory for proof assistants?", I don't know why is it different than here.

It's too long for HN, OP presumably reworded to fit. If you have a better suggestion one of the mods might see and change it, I think OP's chance to edit it has passed though.


"Why is dependent type theory more suitable than set theory for proof assistants?” has 80 characters, which seems to be exactly HN's limit.

Yep, that would be a better rewording. I missed it in my search for a <80 character title.

Nicely done. Changed now. Thanks!

The idea of Lean being suitable for all of math is sensationalist and Kevin knows it. Lean being committed to UIP already rules out many kinds of mathematics. Furthermore, the kind of automation possible in Lean is also possible in univalent theorem provers with the right implementation (e-graphs). They are actually easier in cubical than in Lean (see the 2 pager by Bas Spitters and his masters student).

The difference is that no cubical proof assistant has been implemented by Leo de Moura. Get Leo de Moura to implement cubical, and you will have a proof assistant more powerful than you could ever imagine, built on extremely satisfying foundations.


At least 99% of all mathematicians in academia work with classical logic only, and a good fraction hasn't even heard of anything else. So yeah, Lean might not be suitable for some of the remaining 1%, but that doesn't make Kevin's claim "sensationalist".

It does. And if classical logic is what they like, they can use Isabelle/HOL just as nicely. It is classical. It has wonderful automation. Kevin gets attention because he is bold, not because he is correct.

Anonymous comments are cowardly; please show yourself. If you stay anonymous I am not aware of power dynamics, and I cannot adjust my response accordingly.


I agree with you that it's not obvious that Lean is the only or best option for formalizing "all" or at least most of mathematics. But I didn't get the impression that Kevin thinks that it's the best tool imaginable but rather the best tool that is currently available.

But that wasn't the point: He's right in that constructive/intuitionistic mathematics is so niche that it can be safely ignored when discussing formalization of the mathematics he and almost every other mathematician or scientist is interested in.

Kevin gets attention because he's an accomplished mathematician who tries to formalize his work, or at least what it's based on. I find it ridiculous to dismiss his opinion the way you do.


Lean is not classical. I don't know where the idea that Lean is classical is coming from. Lean is constructive. It is consistent with classical axioms, just like Coq is, and just like Cubical is in the propositional fragment. Isabelle/HOL on the other hand is classical, and is quite a natural choice if classical logic is what you want, which is why mathematicians have been using it for decades now.

I know Kevin. He does good work. He also heckled every talk at ITP, including my own, in the middle to express his opinions. I have never met another researcher in my life who does that. Media outlets interview him and not the other 50 years of researchers doing work on proof assistants and using them both for mathematics and for verifying systems. I wrote a whole book about the history of program verification and for sure nobody has ever interviewed me about it. Kevin is loud and bold, that is why his opinions spread like fire. But they are just that, opinions.


It's because the mathlib authors don't really care about being constructive and frequently use things like choice/LEM, in contrast to Coq/math-comp. If there's a constructive and non-constructive version of something, the mathlib people will use whatever's easier or nicer to work with. There's some info here about how Lean does realizability with pervasive use of choice: https://github.com/coq/coq/issues/10871#issuecomment-5466412...

That makes sense! I just wish discussion on this end would stay nuanced: In that case Lean has great library support for classical mathematics. This is an important distinction because it is something that the authors of other constructive proof assistants can focus on if they want to reach more mathematicians.

Sort of the official policy is that inside proofs (i.e., terms of types in Prop) constructibility doesn't matter, but inside definitions (i.e., terms of types in Type 0 and above) try to be constructive. For example, it is ok to define a function constructively but with a nonconstructive proof of termination.

LEM is used everywhere because it's actually a theorem. It follows from functional extentionality and the existence of quotient types. https://github.com/leanprover/lean/blob/master/library/init/...

The axiom of choice is an actual axiom, and it too ends up being used everywhere, but mostly to introduce decidable instances to permit things like double negation elimination inside proofs. An illustration: [1] introduces these instances to the file and [2] implicitly uses the instance.

[1] https://github.com/leanprover-community/mathlib/blob/master/... [2] https://github.com/leanprover-community/mathlib/blob/master/...


It is my understanding that functional extensionality in Lean itself follows from the axiom propositional extensionality, so in that sense LEM is still a consequence of an axiom. The core theory of Lean is constructive.

I'm not an expert on the foundations of Lean, but I do know that funext in the source code follows only from the axioms of quotient types and the eliminator for equality. There are a number of axioms that are implicit in the type checker itself, so you might say that proof irrelevance is built-in in that way. Propositional extensionality (propext) is that propositions that imply each other are equal, and that's an axiom in the library, but funext does not depend on propext.

Correcting my non-expert inaccuracies in this thread: I just learned that Diaconescu's theorem depends on the axiom of choice, which I'd missed even though I'd glanced at the code for classical.em a few times. So, LEM definitely depends on the axiom of choice in Lean.

LEM and double-negation elimination is very poor style from a constructive POV, though. If you need to prove something non-constructively, just stick to the negative fragment.

I think your comment illustrates a difference in cultures -- mathematicians generally don't care about whether it's bad style in the constructive POV. Sure, you can 'just' stick to the negative fragment, but that 'just' is sweeping a lot of questions of ergonomics under the rug. One thing that attracted me to Lean was that I could formalize mathematics as I knew it, more or less, and there was a vibrant community with a fairly well developed library of basic classical mathematics.

I'm not saying these concerns about constructibility aren't unimportant. I do appreciate both POVs. I just don't think it's something you have to force mathematicians to worry about if all they're interested in is formalizing their math on a computer.

Something that's interesting about Lean is that double-negation elimination is used in Prop but not generally in Type and above. You have to explicitly reach for the axiom of choice if you want to "construct" a term of a type that isn't empty.


> Sure, you can 'just' stick to the negative fragment, but that 'just' is sweeping a lot of questions of ergonomics under the rug.

With all due respect, that seems a bit vague to me. What are the "questions of ergonomics" you're thinking of here? Choosing the negative form of a goal whenever you have to prove something non-constructively seems even easier ergonomically than, e.g. adding LEM as an axiom. You basically don't have to change your proof methods as long as the statement you're proving is of the appropriate form.


Ergonomics to me means "what is the moment-to-moment experience of a user of the language, in particular frictions between what the user wants to say and how it must be said." For someone who does not care much about constructibility, it is better not having to do anything differently depending on whether or not something is constructive. The workaround for such people could be to always include at least one negation for every statement, but that's a pervasive reminder of questions of constructibility! If practitioners are going to be using this transformation by default, then the language would be more ergonomic if it was just automatic.

I don't think having to think about constructibility all the time is more ergonomic than accepting that the system has a well-accepted axiom. There doesn't need to be a one-true system, of course, and for people interested in foundations, reverse mathematics, constructive mathematics, higher category theory, and homotopy type theory, there are other systems. Most mathematicians don't study these things, and accepting LEM is natural for them.


> For someone who does not care much about constructibility, it is better not having to do anything differently depending on whether or not something is constructive.

Well, there are many possible constructive 'versions' of any non-constructive statement, so 'not having to do anything or be reminde[d] of questions of constructivity', strictly speaking, leads to just sticking to the non-constructive version by default. Since it's easy, even in constructive logic, to derive the non-constructive 'version' of some statement from a constructive one, this transformation (properly understood) is as good as automatic.


Right, that's what I am getting at. If it is as good as automatic, why make a mathematician do the transformation themselves? Why make them look at and manipulate all the transformed statements when they're working out a tactic proof?

Whether or not a proposition is constructive is not something I've ever heard any mathematicians in my department ever worry about. I have only ever heard about, for example, showing a certain bound was "effective" after showing that there was a bound at all. Effective means that there is some procedure to construct the number -- but no one cares about whether the argument that shows this number is an upper bound is itself constructive. Lean with its Prop, Type 0, Type 1, ... universe hierarchy is sort of well suited for this.

I'm sure that there are interesting questions that hinge on constructibility in a proof, but again, mathematicians I talk to have never seriously thought about these things. In my field (topology), we do worry about constructing objects and invariants (and sometimes we even care about the complexity class), but at the proof level everything is classical.

If you're involved in developing proof assistants and you want mathematicians to use it, then I would suggest making it so you can change the "reasoning monad" in a file. If you put it in classical mode, it should look like you're able to use LEM, etc., and the goal window should show only untransformed statements, but then when outside the classical monad a constructivist would see the transformed statements. This would be sufficiently ergonomic.


> Why make them look at and manipulate all the transformed statements

Broadly speaking, because it's useful to have a marker of "was this statement derived via a proof by contradiction, or something like that?", and using the negative form is a sensible way of showing this.

> In my field (topology), ... at the proof level everything is classical.

On the contrary, constructive logic is found quite naturally (even in ordinary mathematics!) as the "internal language/logic" of some structures that are of interest to topologists. HoTT itself was designed as a logical foundation that works naturally with homotopies.


> it's useful to have a marker

To whom? (That is rhetorical. The point is that this is not useful information for most mathematicians -- if you picked up a random graduate textbook in, say, algebra or combinatorics, I am certain the theorems will not be annotated with which are proved by contradiction. Quoting you from earlier, "With all due respect, that seems a bit vague to me.")

> are of interest to topologists

I didn't mean to suggest I was speaking for all of topology (more specifically, I'm interested in low-dimensional topology), but still topology is a large field and what you are talking about is a small part of it. Also, just because there are constructive internal logics, I'm not sure that means the system you use to study them has to be constructive itself, and if that's what you are interested in studying you might want a more specialized system anyway.

You don't need to convince me that these things are interesting -- I have some knowledge about internal logics and I do some higher category theory. It's just that languages should be ergonomic for their users. Saying something is easy does not prove it is ergonomic.

Think about this: Most mathematicians I know that use Lean seem to turn on all the additional features that make it as classical as possible. They don't even want the inconvenience of marking definitions noncomputable.

(Maybe you're already familiar with how Lean works, but LEM and double negation elimination do not let you leak values to the Type level from the Prop level. A proof that there is a number with a specific property doesn't mean you actually can have such a number. You need the noncomputable choice function to "obtain" a value from an existential.)


I have learned more about Kevin and feel bad for bringing up the heckling thing now. I would ignore that part of what I said.

Saying Lean "rules out many kinds of mathematics" and not giving a single example, sounds more sensationalist to me. I also don't see what's wrong with anonymous comments as long as they are constructive and people are nice.

I don't know Kevin as well as you do (apparently) but maybe he is just ignorant on the topics you know so much about. Why something gets attention of media (Quanta Magazine?) is complicated. From your comments, you also seem very "bold".


I'm a woman though, and women rarely get positive attention for anything in CS. I'm bold because as a woman in the field you need to be bold to survive as a researcher. In the type theory and proof assistant worlds there are only a handful of us. A typical ratio at a conference for proof assistant research is 1 woman for every 40 men.

Anonymous comments scare me because there are (a few, thankfully not many) abusive people in the PL community I am afraid of engaging with. I don't want to accidentally find myself arguing with one of them. I need to know when to exit the conversation.

Proof relevant mathematics, higher category theory, lots of topology. Sorry. I don't spend all of time on HackerNews, I sometimes don't get around to responding to things. I am talking to Kevin about this framing so we can figure out how to make it healthier in the future. Some of my comments about Kevin were likewise out of line because I interpreted some of our previous interactions as rooted in a gender-based power dynamic when they were actually just rooted in something Kevin finds difficult and wants to do better at, and that is my honest mistake.


I'm a beginner in proof assistents, can you give some examples of many kinds of math ruled out? And what is UIP?

UIP is uniqueness of identity proofs. It's an axiom that says that all proofs of x = y (that two terms are propositionally equal) are the same.

Now, UIP is valid if the only way of proving an equality is to show that the two terms are definitionally equal. However, there are various type theories, such as Homotopy Type Theory, in which this axiom does not hold because propositional equality can have other proofs.


UIP is "unicity of identity proofs". I think this will rule proofs where we wish to talk about proofs of equality of two objects. I don't know off the top of my head any math that wants to do such a thing, but I'm far from an expert.

Can you give a practical example of how denying UIP helps with tasks like writing a proof or a definition rather than defining a really exotic inductive type?

Lean is a classical theory, I don't see how any intuitionistic theory can hope to possibly compete. A mathematician would laugh you out of the store if you tried to get them to used cubical Lean (Lean 2 by the way implemented HoTT ideas) and give up classical logic.

The HoTT people are doing good work and I don't doubt that automation can help with the _significant_ additional complexity of higher dimensional cubes, but that's not really all that would be missing.

Finally, if you can't claim Lean is good enough for all Mathematics then you can't claim it for any existing system or any system that doesn't take classical logic seriously (postulating an axiom doesn't count).


I'm confused by "postulating an axiom doesn't count". Are you aware that choice is an axiom in Lean? https://github.com/leanprover-community/lean/blob/master/lib...

Proving "classical" propositions in an intuitionistic system is trivial. Intuitionistic logic can be viewed as an extension of classical logic with new "constructive OR" and "constructive EXISTS" operators. The classical operators are recovered via negation: NOT (NOT a AND NOT b) is classical OR, whilst NOT FORALL x (NOT p) is a classical existential quantifier.

>Finally, if you can't claim Lean is good enough for all Mathematics then you can't claim it for any existing system or any system that doesn't take classical logic seriously (postulating an axiom doesn't count).

Correct me if I'm wrong (I may well be), but couldn't one work classically just by sticking to (-1)-truncated types ("mere prepositions") in a HOTT based system, for which LEM is true by default?


LEM for mere propositions is not "true by default", but it is consistent with univalence. So you can take it as an axiom.

Lean isn't classical.

Lean is the calculus of inductive constructions with uniqueness of identity proofs. Classical logic in Lean requires using axioms.


Are you talking along the lines of the red family of provers?

What makes the cubical approach more powerful? What makes lean weak?


There is RedPRL, there is also cubical Agda. I think cubical Agda is the best developed so far. It lacks automation. But that is not fundamental, it is thanks to the philosophies of the people involved.

Lean is not weak, it just commits to something called Uniqueness of Identity Proofs (UIP). This is inconsistent with Univalence, a property that cubical type theories have. Necessarily, neither system can express "all of math." So it goes.

Leo chose UIP to get a novel way to get really powerful automation of equality proofs. Leo is very, very good at this; this is his whole shindig. But he had to hack around things a bit in order to get what he wanted. The paper by Bas and his student shows that in cubical, you don't have to hack around things; this automation of equality proofs arises in the natural way.

The gap is not fundamental, and it irritates me when it is attributed to the choice of UIP. The reason Lean is so useful is because the people working on it are good at building automation. The people working on cubical are much more interested in foundations. We need people who are interested in automating cubical; once we get that, the proof assistant that arises from it will be better than anything we have ever seen.


Do you have any introductory material on cubical type theory, suitable for the average mathematician? The type theory in Lean feels dead simple to me, but all the online resources on cubical type theory feel impenetrable.

I like these lecture notes: https://staff.math.su.se/anders.mortberg/papers/cubicalmetho...

But if that is too hard to read, I recommend telling Anders directly when you get confused. He is open to improving the notes.


> all the online resources on cubical type theory feel impenetrable.

Same here.


Slightly off-topic, but in any mathematical theory concerning a certain restricted domain and also in any theory attempting to cover the entire mathematics there are many possible choices for the primitive concepts and rules.

In most cases it is not possible to have an objective criterion for deciding which is the best choice, so the choice remains based on personal preferences.

For example, I could never accept the idea that set theory can be considered to belong to the foundations of mathematics.

I have always believed that it is more convenient to view the sets not as primitives, but as classes of equivalence of the ordered sequences, which in turn are constructed from ordered pairs, which are a primitive concept.

So instead of using set theory as a base, I believe it to be more convenient to start from some primitives that include some of the concepts and operations on which LISP was also based, plus some definitions, which normally are introduced using sets, modified to use ordered sequences instead.

All the set theory (and the number theory) can be constructed from these alternative primitive concepts.


That doesn't work as written for uncountable sets.

That's true, but there's an amusingly odd theorem (downwards Lowenheim-Skolem) that implies that if set theory has a model, it has a countable model. So, in a sense, all sets are countable. I think this just leads you to the next problem, which is that (I think) it would be undecidable normalizing and sorting these sets.

Here is a plan to improve proof assistants, and it is based on set theory: https://www.practal.com

Program extraction.

In dependent type theory if you've proved "A implies B" you can extract from that proof a program that takes an argument of type A and always halts, returning a value of type B. Moreover if you prove some property about proofs that A implies B, you've also proved the corresponding proposition about programs.

This means your proofs get to deal with programs directly, rather than having to formalize them as something like Turing machines whose tapes are set-theoretic encodings of lists of integers. It's excruciatingly painful to write non-hand-wavy proofs of anything that way. Hand-wavy proofs that can't be machine-checked aren't so bad of course; complexity theory folks have been doing that for decades.

If you aren't proving things about programs or homotopy then there really aren't any obvious reasons to prefer dependent type theory. I say this as somebody who loves programming with dependent types. But I'm being honest here, and I wish more people in the mechanized mathematics world would be honest about this.


> there really aren't any obvious reasons to prefer dependent type theory

The OP gives a reason, and it's the same reason programs use types. Untyped proofs are usually wrong, like untyped programs.


HOL is typed, but not a dependent type theory. HOL is also a classical logic. HOL is essentially Alonzo Church's simply typed lambda-calculus [1] from 1940. Classical, rather than constructive logic tends to give shorter proofs.

[1] A. Church, A Formulation of the Simple Theory of Types. https://pdfs.semanticscholar.org/28bf/123690205ae5bbd9f8c84b...


Er, no. Even Coq proofs are written in an untyped language (Ltac). You've got your levels mixed up.

> A set 𝑋 is jaberwocky when for every π‘₯βˆˆπ‘‹ there exists a bryllyg π‘ˆβŠ†π‘‹ and an uffish πΎβŠ†X such that π‘₯βˆˆπ‘ˆ and π‘ˆβˆˆπΎ.

Anyone know how this relates to Lewis Carrol?


Jabberwocky is a poem by Lewis Carroll.

https://en.wikipedia.org/wiki/Jabberwocky


And the idea in the context of the original post is that this is supposed to be a parody of a formal math definition in a paper or textbook (using Jabberwocky vocabulary instead of real math vocabulary).

Not that it makes sense anyway. Somehow π‘ˆβŠ†π‘‹ and π‘ˆβˆˆπ‘‹.

No, the point was that π‘ˆβˆˆπ‘‹ is a typo and π‘ˆβŠ†π‘‹ is what was intended. Type theory will reject the mistake but set theory will accept it. This is then presented as a reason why mathematicians should prefer type-theory-based proof assistants to set-theory-based ones, since the former will catch these kinds of mistakes while the later won't.

That is exactly the point being made. That you can spot right away that something "doesn't make sense".

That’s possible. For instance, X = {{}} and U = {}. Or in general, if X_0 = {} and X_{i+1} = {X_0, ..., X_i}, then X_i is both an element and a subset of X_j whenever i < j.

That happens all the time with ordinals.

It is just a way to hide the definition of local compactness of a topological space with a mistake (should be U included in K).



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: