-
Notifications
You must be signed in to change notification settings - Fork 259
[ refactor ] (more) decidable Data.Fin.Properties
#2744
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Data.Fin.PropertiesData.Fin.Properties
|
Thanks @MatthewDaggitt for the feedback:
I'll move to DRAFT for the time being, and remove from v2.3, while I reconsider things. |
JacquesCarette
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the code seems fine. Only issues are that things seem to have moved without a good reason to.
|
Hmmm... @JacquesCarette the code motion was in response to earlier review comments from @MatthewDaggitt , but maybe I misunderstood his intention. Nevertheless, the |
|
I had seen some of the conversation. This is why maybe a larger break up ( |
|
Last addition: dual version of |
|
@JacquesCarette If you are happy with the revisions, then we could add this to the v2.3 docket? |
JacquesCarette
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not thrilled with where the Effectful have ended up, but not a hill I'm willing to die on.
|
|
||
| {-# OPTIONS --cubical-compatible --safe #-} | ||
|
|
||
| module Data.Fin.Relation.Unary.Base where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this Base module?
|
|
||
| ------------------------------------------------------------------------ | ||
| -- search | ||
| -- a Decidable predicate is either always true, or has a smallest counterexample |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Capitalisation and formatting of this header could be better?
| syntax Universal< (λ j → P) i = ∀[ j < i ] P | ||
|
|
||
| ExistsMinimalCounterexample : (P : Pred (Fin n) p) → Set p | ||
| ExistsMinimalCounterexample P = ∃[ i ] ¬ P i × ∀[ j < i ] P j |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could just call this MinimalCounterexample? Making this a record with named fields would make it easier to read as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a record not a bad idea...
| ExistsMinimalCounterexample : (P : Pred (Fin n) p) → Set p | ||
| ExistsMinimalCounterexample P = ∃[ i ] ¬ P i × ∀[ j < i ] P j | ||
|
|
||
| syntax ExistsMinimalCounterexample P = μ⟨¬ P ⟩ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still kind of against this for readability reasons, but why does this have to be a syntax declaration rather than an ordinary infix declaration?
|
|
||
| ------------------------------------------------------------------------ | ||
| -- Fin | ||
| ------------------------------------------------------------------------ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this and Bundles have been moved? To be they logically make sense to live at the top of the file as they related to the type itself, rather than functions or relations over it.
| ------------------------------------------------------------------------ | ||
|
|
||
| open import Data.Fin.Relation.Unary.Base public | ||
| open import Data.Fin.Relation.Unary.Decidable public |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced about this direction of dependencies.
|
|
||
|
|
||
| Universal< : Pred (Fin n) p → Pred (Fin n) p | ||
| Universal< P i = (j : Fin′ i) → P (inject j) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we use Fin' and inject here rather than an explicit j < i proof? Generally Fin' is quite difficult to work with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is pure legacy! The refactoring here was designed to make an existing (however poorly expressed) statement derivable from something stronger...
|
|
||
| syntax ExistsMinimalCounterexample P = μ⟨¬ P ⟩ | ||
|
|
||
| searchMin : Decidable P → (∀ i → P i) ⊎ ∃[ i ] ¬ P i × ∀[ j < i ] P j |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about calling this searchForCounterexample and the one below searchForWitness?
|
Again has merge conflicts, no one waiting on it particularly and @jamesmckinna is away so bumping to v2.4 |
|
Happy to bump! There was enough feedback/pushback on some of the choices I'd made that this one deserves a bit more time/energy/thought. |
|
I'm going to close this one for now, not least because, as is usual for me, the PR tries to do too many things at once:
It's a mess that I don't quite feel like untangling, except as separate PRs for each of the above, and certainly not now. |
|
(Oops, didn't notice it was subsequently closed before commenting.) |
This PR refactors some proofs about
Decidablepredicates onFin n, to clarify some, and to add others, including some additionalsyntax, around a independently interesting minimisation principle from which certain others follow.A downstream refactoring might reconsider these things in terms of specialisation of lemmas in
Induction.InfiniteDescent.Outstanding issue: could be more systematic about use of
variables to clean the whole module up?