Skip to content

Conversation

@digama0
Copy link
Member

@digama0 digama0 commented May 4, 2025

Incl. minor formatting of Trans.lean.

fixes #1222

@digama0 digama0 requested a review from fgdorais May 4, 2025 16:29
@github-actions github-actions bot added the awaiting-review This PR is ready for review; the author thinks it is ready to be merged. label May 4, 2025
leanprover-community-mathlib4-bot added a commit to leanprover-community/mathlib4 that referenced this pull request May 4, 2025
@leanprover-community-bot
Copy link
Collaborator

leanprover-community-bot commented May 4, 2025

Mathlib CI status (docs):

@fgdorais
Copy link
Collaborator

fgdorais commented May 4, 2025

I added a MWE test for the Mathlib build failures but I haven't investigated the issue.

leanprover-community-mathlib4-bot added a commit to leanprover-community/mathlib4 that referenced this pull request May 4, 2025
@fgdorais
Copy link
Collaborator

fgdorais commented May 6, 2025

The remaining Mathlib error seems to be a term depth issue:

error: /home/lean/actions-runner/_work/mathlib4/mathlib4/Mathlib/LinearAlgebra/AffineSpace/AffineEquiv.lean:263:2: @[trans] attribute only applies to lemmas proving
        x ∼ y → y ∼ z → x ∼ z, got 
  {k : Type u_1} →
    {P₁ : Type u_2} →
      {P₂ : Type u_3} →
        {P₃ : Type u_4} →
          {V₁ : Type u_6} →
            {V₂ : Type u_7} →
              {V₃ : Type u_8} →
                [inst : Ring k] →
                  [inst_1 : AddCommGroup V₁] →
                    [inst_2 : AddCommGroup V₂] →
                      [inst_3 : AddCommGroup V₃] →
                        [inst_4 : Module k V₁] →
                          [inst_5 : Module k V₂] →
                            [inst_6 : Module k V₃] →
                              [inst_7 : AffineSpace V₁ P₁] →
                                [inst_8 : AffineSpace V₂ P₂] →
                                  [inst_9 : AffineSpace V₃ P₃] →
                                    (P₁ ≃ᵃ[k] P₂) → (P₂ ≃ᵃ[k] P₃) → P₁ ≃ᵃ[k] P₃ with target 
  P₁ ≃ᵃ[k] P₃

@digama0
Copy link
Member Author

digama0 commented May 6, 2025

I don't think it's term depth, unless it's a problem of inferring the Trans instance. Could you make a MWE version of this example?

@fgdorais
Copy link
Collaborator

fgdorais commented May 6, 2025

Added MWE test case. Looks like it's about an unusual ordering of parameters.

@fgdorais
Copy link
Collaborator

I did a bit of digging, the issue with the MWE is that mkAppOptM' in RelKind.mkRel can't infer the M k V instances while adding the trans instance. Changing the order to

def MT.rel {V₁ V₂} (k P₁ P₂) [M k V₁] [M k V₂] [T V₁ P₁] [T V₂ P₂] := Unit

fixes that but mkRel still has issues in the trans tactic.

@fgdorais fgdorais added awaiting-author Waiting for PR author to address issues and removed awaiting-review This PR is ready for review; the author thinks it is ready to be merged. labels Jul 7, 2025
@fgdorais fgdorais added the help wanted Extra attention is needed label Jul 24, 2025
@staroperator
Copy link

I did a bit of digging, the issue with the MWE is that mkAppOptM' in RelKind.mkRel can't infer the M k V instances while adding the trans instance. Changing the order to

def MT.rel {V₁ V₂} (k P₁ P₂) [M k V₁] [M k V₂] [T V₁ P₁] [T V₂ P₂] := Unit

fixes that but mkRel still has issues in the trans tactic.

I feel the problem is that mkAppOptM' tries to synthesize the instances but we want to make them mvars as more as possible. A smaller MWE for your new version is

class C (k α : Type)
def C.rel (k : Type) (α β : Type) [C k α] [C k β] := Unit
@[trans] def C.trans {k α β γ : Type} [C k α] [C k β] [C k γ] : rel k α β → rel k β γ → rel k α γ := sorry

def aaa {k α β γ : Type} [C k α] [C k β] [C k γ] : C.rel k α β → C.rel k β γ → C.rel k α γ := by
  intro h₁ h₂
  trans β
  · exact h₁
  · exact h₂

The C.trans is registered as decl C.trans, key #[C.rel, _uniq.3342], kind global but key #[C.rel] is expected. I guess this is because getExplicitRelArg succeeds at C.rel k but fails at C.rel _ due to instance synthesis.

@staroperator
Copy link

I feel the problem is that mkAppOptM' tries to synthesize the instances but we want to make them mvars as more as possible. A smaller MWE for your new version is

class C (k α : Type)
def C.rel (k : Type) (α β : Type) [C k α] [C k β] := Unit
@[trans] def C.trans {k α β γ : Type} [C k α] [C k β] [C k γ] : rel k α β → rel k β γ → rel k α γ := sorry

def aaa {k α β γ : Type} [C k α] [C k β] [C k γ] : C.rel k α β → C.rel k β γ → C.rel k α γ := by
  intro h₁ h₂
  trans β
  · exact h₁
  · exact h₂

The C.trans is registered as decl C.trans, key #[C.rel, _uniq.3342], kind global but key #[C.rel] is expected. I guess this is because getExplicitRelArg succeeds at C.rel k but fails at C.rel _ due to instance synthesis.

And an amazing fact: you can complete aaa with

def aaa {k α β γ : Type} [C k α] [C k β] [C k γ] : C.rel k α β → C.rel k β γ → C.rel k α γ := by
  intro h₁ h₂
  trans β
  · exact h₁

#print aaa

It gives

def aaa : {k α β γ : Type} →
  [inst : C k α] → [inst_1 : C k β] → [inst_2 : C k γ] → C.rel k α β → C.rel k β γ → C.rel k α γ :=
fun {k α β γ} [C k α] [C k β] [C k γ] h₁ h₂ => h₁

which should not type check. Is this a soundness bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting-author Waiting for PR author to address issues breaks-mathlib help wanted Extra attention is needed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

trans does not work on implicit arguments

5 participants