feat: let dot notation see through CoeFun instances#5692
Merged
kmill merged 6 commits intoleanprover:masterfrom Oct 14, 2024
Merged
feat: let dot notation see through CoeFun instances#5692kmill merged 6 commits intoleanprover:masterfrom
CoeFun instances#5692kmill merged 6 commits intoleanprover:masterfrom
Conversation
Projects like mathlib use projection fields with extra structure, for example one could imagine defining `Multiset.card : Multiset α →+ Nat`, which bundles the fact that `Multiset.card (m1 + m2) = Multiset.card m1 + Multiset.card m2`. A problem though is that so far this has prevented dot notation from working: you can't write `(m1 + m2).card = m1.card + m2.card`. With this PR, now we can. The way it works is that "LValue resolution" will apply CoeFun instances when trying to resolve which argument should receive the object of dot notation. This also adds in a small optimization that the parameter list computation in LValue resolution uses `forallTelescope` instead of `forallTelescopeReducing`, lazily reducing when a relevant parameter hasn't been found yet. Closes leanprover#1910
ghost
pushed a commit
to leanprover-community/batteries
that referenced
this pull request
Oct 13, 2024
ghost
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 13, 2024
|
Mathlib CI status (docs):
|
ghost
pushed a commit
to leanprover-community/batteries
that referenced
this pull request
Oct 13, 2024
Collaborator
Author
|
!bench |
ghost
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 13, 2024
Collaborator
|
Here are the benchmark results for commit 56c5b87. |
ghost
pushed a commit
to leanprover-community/batteries
that referenced
this pull request
Oct 13, 2024
ghost
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
Oct 13, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Projects like mathlib like to define projection functions with extra structure, for example one could imagine defining
Multiset.card : Multiset α →+ Nat, which bundles the fact thatMultiset.card (m1 + m2) = Multiset.card m1 + Multiset.card m2for allm1 m2 : Multiset α. A problem though is that so far this has prevented dot notation from working: you can't write(m1 + m2).card = m1.card + m2.card.With this PR, now you can. The way it works is that "LValue resolution" will apply CoeFun instances when trying to resolve which argument should receive the object of dot notation.
A contrived-yet-representative example:
Design note 1: While LValue resolution attempts to make use of named arguments when positional arguments cannot be used, when we apply CoeFun instances we disallow making use of named arguments. The rationale is that argument names for CoeFun instances tend to be random, which could lead dot notation randomly succeeding or failing. It is better to be uniform, and so it uniformly fails in this case.
Design note 2: There is a limitation in that this will not make use of the values of any of the provided arguments when synthesizing the CoeFun instances (see the tests for an example), since argument elaboration takes place after LValue resolution. However, we make sure that synthesis will fail rather than choose the wrong CoeFun instance.
Performance note: Such instances will be synthesized twice, once during LValue resolution, and again when applying arguments.
This also adds in a small optimization to the parameter list computation in LValue resolution so that it lazily reduces when a relevant parameter hasn't been found yet, rather than using
forallTelescopeReducing. It also switches to usingforallMetaTelescopeto make sure the CoeFun synthesis will fail if multiple instances could apply.Getting this to pretty print will be deferred to future work.
Closes #1910