Zulip Chat Archive
Stream: lean4
Topic: Asking for simplifications in proofs/type-checking
Siddhartha Gadgil (Sep 26 2021 at 06:04):
When updating the nightly build by a month (in sync with mathlib4), some of my code no longer typechecked. A somewhat minimized version of what causes the problem is as in the example below:
def eg1IsFalse : Bool := eg1Soln.isSat
#eval eg1IsFalse -- gives false
example : eg1IsFalse = false := rfl -- gives an error
Is there some way I can ask eg1False
to be simplified when making the definition, or some tactic replacing rfl
where we reduce to normal form?
Thanks.
Yakov Pechersky (Sep 26 2021 at 11:42):
Let's say your definition was originally 1 + 0, your eval gave 1, and your example 1 + 0 = 1 := rfl worked. But then the definition of addition changed (such that zero on the left was the defintional equality), so your original rfl proof would no longer work.
Yakov Pechersky (Sep 26 2021 at 11:42):
My understanding is that rfl is the proof only if #reduce would have given you false.
Siddhartha Gadgil (Sep 26 2021 at 11:56):
I just checked: #reduce eg1IsFalse
does indeed give false
.
In my case eg1Soln
is complicated and involves propositions in its constructions, so I am guessing that some optimization is stopping reduction, and I should force it by an annotation or tactic.
Siddhartha Gadgil (Sep 26 2021 at 13:20):
I have been checking further what simplifications are made. Here are some experiments:
#print eg1IsFalse
#print eg1Soln
give as info
def eg1IsFalse : Bool :=
SatSolution.isSat eg1Soln
def eg1Soln : SatSolution eg1Statement :=
solveSAT eg1Statement
So it looks as if eg1Solution
is not being simplified. I also tried to force it to whnf
and got the following error, perhaps because I misunderstand whnf
syntax (name:= normalform)"whnf!" term : term
@[termElab normalform] def normalformImpl : TermElab :=
fun stx expectedType? =>
match stx with
| `(whnf! $s) =>
do
let t ← elabTerm s none
let e ← whnf t
return e
| _ => Lean.Elab.throwIllFormedSyntax
def eg1SolnNorm := whnf! eg1Soln
the definition at the end gives the error:
application type mismatch
_.codom
argument has type
Unit
but function has type
Containment eg1Statement → Nat
Indeed the function does have the type Containment eg1Statement → Nat
and everything compiles fine since this is the type of the argument at compile time. But at the meta level apparently it is getting either optimized to Unit
deliberately or distorted in some other way.
Any clarifications will be appreciated. The meta stuff here is just my exploring with limited knowledge, my real question is whether I can make the interpreter simplify eg1Soln
.
Siddhartha Gadgil (Sep 26 2021 at 14:06):
This is getting curiouser and perhaps is a bug. There is a change in behaviour between the nightly builds "leanprover/lean4:nightly-2021-09-19" and "leanprover/lean4:nightly-2021-09-20" where whnf
is failing. Here is some local output for the earlier build with whnf!
as above:
We normalize with
def eg1isFalseNormal := whnf! eg1IsFalse
then the outputs for the following are:
#print eg1IsFalse -- def eg1IsFalse : Bool := SatSolution.isSat eg1Soln
#print eg1isFalseNormal -- def eg1isFalseNormal : Bool :=false
which is what I expect. However, in the newer versions of lean, as mentioned above the normalization gives an error.
Any clarification is appreciated.
Last updated: Dec 20 2023 at 11:08 UTC