Zulip Chat Archive

Stream: lean4 dev

Topic: isDefEq on structures


Reid Barton (Jan 30 2023 at 08:22):

mathlib's algebraic hierarchy design involves a lot of "defeq diamonds" which I have parodied in the following form.

structure Gr (α : Type) where
  add : α  α  α
  add_comm :  (a b : α), add a b = add b a

def gr1 : Gr Nat where
  add x y := x + y
  add_comm x y := Nat.add_comm x y

def gr2 : Gr Nat where
  add x y := (x + y) + 0
  add_comm x y :=
    show (x + y) + 0 = (y + x) + 0
    from Nat.add_comm x y

set_option trace.Meta.isDefEq true in
#check (rfl : gr1 = gr2)

To check that gr1 and gr2 are defeq Lean checks that the add fields are defeq three times. The last two are to check that the types of the add_comm fields are defeq. But of course they have to be once the add fields are, because that's how structures work.
Couldn't Lean do better here?
(The trace output below is actually printed twice, but I think that's due to some detail of the way I set up the defeq test.)

trace output

Reid Barton (Jan 30 2023 at 08:25):

This is extremely bad when combined with the way Lean checks defeq of projections (which lean4#2003 is about) if gr1 and gr2 are actually defined in terms of some other structures say comm_gr1 and comm_gr2 because checking equality of each field of the gr* triggers checking equality of the entirety of the comm_gr* structures, leading to huge blowups if this pattern is nested.
But even in a simple case like the one above we could save a lot of work by not testing things repeatedly.

Reid Barton (Jan 30 2023 at 08:27):

A related question which came up is whether, when we test isDefEq of two expressions, we are supposed to be allowed to assume that their types are already known to be defeq. This is the way type theories are usually presented on paper so I was assuming it was allowed to assume this, but Lean seems not to use this knowledge (for testing defeq of propositions specifically) so maybe it is not intended to be a precondition.

Reid Barton (Jan 30 2023 at 08:41):

As the example shows it's not just one extra check per "axiom" (like add_comm), but one per occurrence of a field in the axiom. So comm is 2, assoc is 4, distrib is 5, etc. Already for a Ring, it adds up fast.

Reid Barton (Jan 30 2023 at 08:45):

On the bright side, we can say that there is finally some practical purpose to figuring out whether the right unit axiom of a group follows from the left unit axiom

Kevin Buzzard (Jan 30 2023 at 09:40):

You might find that hard to remove that axiom even if you can prove it from the others, because group extends monoid and it's not true for monoids.


Last updated: Dec 20 2023 at 11:08 UTC