Skip to content
This repository was archived by the owner on Jul 24, 2024. It is now read-only.

[Merged by Bors] - feat(order/well_founded): typeclasses for well-founded < and >#15399

Closed
vihdzp wants to merge 9 commits intomasterfrom
wf_rel_class_v2
Closed

[Merged by Bors] - feat(order/well_founded): typeclasses for well-founded < and >#15399
vihdzp wants to merge 9 commits intomasterfrom
wf_rel_class_v2

Conversation

@vihdzp
Copy link
Copy Markdown
Collaborator

@vihdzp vihdzp commented Jul 15, 2022

Well-founded typeclasses

We introduce a new unbundled typeclass is_well_founded for a general well-founded relation, and reducible defs well_founded_lt and well_founded_gt for well-founded < and > specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses.

This is just an initial development. If this is merged, a subsequent PR will redefine is_well_order in terms of is_well_founded (and remove the redundant irrefl field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib.

Moved from #15023.

Why do we want this?

Here's the part where I justify why this is a good thing we want in mathlib.

Well-ordered <

There is a need to talk about well-ordered < relations, as a quick search for is_well_order α (<) or is_well_order ι (<) reveals. The most obvious way to spell this condition out, namely [has_lt α] [is_well_order α (<)] is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write [linear_order α] [is_well_order α (<)] instead.

With this new typeclass, the obvious spelling is now the good one: [linear_order α] [well_founded_lt α]

Redundant typeclasses

We actually already at least four typeclasses for the well-foundedness of a concrete relation: category.noetherian_object, category.artinian_object, topological_space.noetherian_space, and wf_dvd_monoid. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them reducible defs, would alleviate this problem.

Typeclass inference

Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including measure and order.preimage), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders.

Misleading theorem names

Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as <, that is. This leads to misleading theorem names when you're using them on a well-founded > relation. With this refactor, we could simply specialize well_founded.min into well_founded_gt.max and end up with clearer theorem statements.

On a related note, given a linear order and a well-founded < relation, we can rephrase well_founded.not_lt_min into the much more convenient well_founded_lt.min_le.


Open in Gitpod

@vihdzp vihdzp added the awaiting-review The author would like community review of the PR label Jul 15, 2022
@vihdzp vihdzp changed the title refactor(order/well_founded): typeclasses for well-founded < and > feat(order/well_founded): typeclasses for well-founded < and > Jul 16, 2022
Copy link
Copy Markdown
Member

@fpvandoorn fpvandoorn left a comment

Choose a reason for hiding this comment

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

LGTM

Since it's a change about basic objects, I'd like someone else to take a look, too.

Copy link
Copy Markdown
Collaborator

@Vierkantor Vierkantor left a comment

Choose a reason for hiding this comment

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

I've been annoyed at the old situation too. Since there are no objections on Zulip so let's get this merged!

bors r+

@leanprover-community-bot-assistant leanprover-community-bot-assistant added ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.) and removed awaiting-review The author would like community review of the PR labels Jul 27, 2022
bors bot pushed a commit that referenced this pull request Jul 27, 2022
…15399)

# Well-founded typeclasses

We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. 

This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib.

Moved from #15023. 

## Why do we want this?

Here's the part where I justify why this is a good thing we want in mathlib.

### Well-ordered `<`

There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead.

With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]`

### Redundant typeclasses

We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem.

### Typeclass inference

Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders.

### Misleading theorem names 

Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements.

On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
@bors
Copy link
Copy Markdown

bors bot commented Jul 27, 2022

Pull request successfully merged into master.

Build succeeded:

@bors bors bot changed the title feat(order/well_founded): typeclasses for well-founded < and > [Merged by Bors] - feat(order/well_founded): typeclasses for well-founded < and > Jul 27, 2022
@bors bors bot closed this Jul 27, 2022
@bors bors bot deleted the wf_rel_class_v2 branch July 27, 2022 19:44
bottine pushed a commit to bottine/mathlib that referenced this pull request Jul 30, 2022
…eanprover-community#15399)

# Well-founded typeclasses

We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. 

This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib.

Moved from leanprover-community#15023. 

## Why do we want this?

Here's the part where I justify why this is a good thing we want in mathlib.

### Well-ordered `<`

There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead.

With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]`

### Redundant typeclasses

We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem.

### Typeclass inference

Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders.

### Misleading theorem names 

Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements.

On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
robertylewis pushed a commit that referenced this pull request Aug 2, 2022
…15399)

# Well-founded typeclasses

We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. 

This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib.

Moved from #15023. 

## Why do we want this?

Here's the part where I justify why this is a good thing we want in mathlib.

### Well-ordered `<`

There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead.

With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]`

### Redundant typeclasses

We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem.

### Typeclass inference

Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders.

### Misleading theorem names 

Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements.

On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
khwilson pushed a commit that referenced this pull request Aug 2, 2022
…15399)

# Well-founded typeclasses

We introduce a new unbundled typeclass `is_well_founded` for a general well-founded relation, and reducible defs `well_founded_lt` and `well_founded_gt` for well-founded `<` and `>` specifically, to be used as mixins. For now, all we do is specialize only the most basic API on well-founded relations to these new typeclasses. 

This is just an initial development. If this is merged, a subsequent PR will redefine `is_well_order` in terms of `is_well_founded` (and remove the redundant `irrefl` field). Further PRs will focus on providing all the possible instances for this new typeclass, and actually using it throughout mathlib.

Moved from #15023. 

## Why do we want this?

Here's the part where I justify why this is a good thing we want in mathlib.

### Well-ordered `<`

There is a need to talk about well-ordered `<` relations, as a quick search for `is_well_order α (<)` or `is_well_order ι (<)` reveals. The most obvious way to spell this condition out, namely `[has_lt α] [is_well_order α (<)]` is actually the most inconvenient, since none of the results for linear orders are available. You actually need to write `[linear_order α] [is_well_order α (<)]` instead.

With this new typeclass, the obvious spelling is now the good one: `[linear_order α] [well_founded_lt α]`

### Redundant typeclasses

We actually already at least four typeclasses for the well-foundedness of a concrete relation: `category.noetherian_object`, `category.artinian_object`, `topological_space.noetherian_space`, and `wf_dvd_monoid`. One currently needs to specialize the characterizing properties of a well-founded relation to these separate typeclasses in order to use them. Redefining these typeclasses in terms of these new ones, and making them `reducible def`s, would alleviate this problem.

### Typeclass inference

Well-founded relations are actually a nice candidate for typeclass inference, since there's many common constructions that automatically preserve well-foundedness. These include taking inverse images (including `measure` and `order.preimage`), maps through relation embeddings (including subtypes), lexicographic sums or products, and adding a top or bottom element. Many of these are currently provided as instances, but only for well-orders.

### Misleading theorem names 

Perhaps the most useful result on well-founded relations is that every nonempty set has a minimum - when you view the relation as `<`, that is. This leads to misleading theorem names when you're using them on a well-founded `>` relation. With this refactor, we could simply specialize `well_founded.min` into `well_founded_gt.max` and end up with clearer theorem statements.

On a related note, given a linear order and a well-founded `<` relation, we can rephrase `well_founded.not_lt_min` into the much more convenient `well_founded_lt.min_le`.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

ready-to-merge All that is left is for bors to build and merge this PR. (Remember you need to say `bors r+`.)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants