Skip to content

feat(Foundations/Relation/Confluence): generalize results from confluence to commutation - #880

Open
thomaskwaring wants to merge 10 commits into
leanprover:mainfrom
thomaskwaring:comm-to-conf
Open

feat(Foundations/Relation/Confluence): generalize results from confluence to commutation#880
thomaskwaring wants to merge 10 commits into
leanprover:mainfrom
thomaskwaring:comm-to-conf

Conversation

@thomaskwaring

Copy link
Copy Markdown
Collaborator

This PR generalises many results from confluent to commuting relations, and obtains the classical case as a specialisation. We add HJoin and MHJoin — heterogenous versions of Join and MJoin — and associated API for them and related relational constructions.

NB: the theorem confluent_equivalents is now public, and the TFAE has been extended with certain other properties which generalise better to the heterogenous case.

@chenson2018 chenson2018 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor organization comments:

Comment thread Cslib/Foundations/Relation/Basic.lean Outdated
Comment on lines +87 to +89
@[simp] theorem hJoin_eq_join : HJoin r r = Join r := rfl

@[grind =] theorem hJoin_eq_comp_swap : HJoin r₁ r₂ = Comp r₁ (swap r₂) := rfl

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the thought behind the split simp and grind =? I'm always a bit suspicious when I don't see them in matching pairs.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think we want the latter as simp — in general i haven't systematically added grind annotations bc my proofs haven't used them (also many of the definitions are abbrev so they're not needed). should i at least add grind = to the simp lemmas where appropriate? i can also look for other possible grind lemmas.

Comment thread Cslib/Foundations/Relation/Basic.lean

theorem MJoin.single (h : ReflTransGen r a b) : MJoin r a b := by
use b
@[deprecated Join.single (since := "2026-09-07")]

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check that this doesn't give a warning under the nightly toolchain? For the last PR there where some +typeChanged that needed to be added. (Which is fine, but I think it's nicer to handle them now)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes will do though you will need to tell me how (sorry!)

Comment thread Cslib/Foundations/Relation/Defs.lean Outdated

/-- The join of the reflexive transitive closure. This is not named in Mathlib, but see
`#loogle Relation.Join (Relation.ReflTransGen ?r)` -/
abbrev MJoin (r : α → α → Prop) := Join (ReflTransGen r)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder a bit how necessary these M variants are. It's harmless since they are abbrev and it does make combinatory logic a bit nicer looking, but otherwise it could be considered redundant.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would support deprecating them — it does make some of the statements less wordy so if you think it's harmless i'm okay with keeping them.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants