theorem_proving_in_lean | Theorem proving in Lean

This works for me

If you import Lean's math's library then the tactic by tauto! should solve all of these. Additionally these are all already library theorems with names like and_comm.

I don't think there are any shorter proofs of these statements from first principles. The only way you can shorten some of the proofs is by removing the haves and shows and making them less readable. Here's my proof of or_assoc, which is essentially the same as yours, but without the haves and shows.

You don't have p ∨ q in the assumptions of this example. So, you have to go from (assume hpqr, _) directly to and_intro. I mean, something like

Your approach, using the first method taught in Theorem Proving In Lean, is not really idiomatic in the sense that the code in Lean's maths library is either written in tactic mode (covered later on in the book) or in full term mode. Here's a tactic mode proof:

The axiom choice in Lean is indeed not the same as the axiom of choice in set theory. The axiom choice in Lean doesn't really have a corresponding statement in set theory. What is says is that there is a function which takes a proof that some type α is nonempty, and produces an inhabitant of α. In set theory, we cannot define functions which take proofs as arguments, since proofs are not objects in set theory, they are in the layer of logic on top of that.

That said, the two choice axioms are not completely unrelated. From Leans axiom choice you can prove the more familiar axiom of choice from set theory, one version which you can find here.

1. eq is defined to be

You are probably familiar with pattern-matching from Lean or some functional programming language, so here is a solution that uses this mechanism:

First off, note that there is nothing dependent about your types. Dependent product is just another name for the Pi type itself (the Pi deriving from the usual mathematical notation for indexed products).

Your prod2 type is the correct maximally explicit version of prod1. In prod3, you changed α and β from inductive parameters to indices, which as you noticed doesn't work out for universe-related reasons. In general, indices are used to define inductive type families as in section 7.7.

Finally, the atomic Type you used in prod4 is an abbreviation of Type 1. You can use Type* to have universe parameters inferred automatically.