[ refactor ] (more) decidable Data.Fin.Properties

[jamesmckinna]

This PR refactors some proofs about Decidable predicates on Fin n, to clarify some, and to add others, including some additional syntax, 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?

[MatthewDaggitt]

Can we not just use yes and no here?

[jamesmckinna]

Yes, but it's my obsessive avoidance of yes and no in favour of their lazier versions... as discussed at length in previous PRs...

[MatthewDaggitt]

We should be able to come up with a better name for this. I guess find minimum?

This return type is also going to be somewhat baffling. Is writing Π[ P ] ⊎ μ⟨¬ P ⟩ really more informative than Universal P ⊎ MinimalCounterexample P?

[jamesmckinna]

Regarding naming, the analogous proof for List is Data.List.Relation.Unary.All.search, but doesn't have a minimality property (we don't prove that it returns the first counterexample)

Regarding the type, yes, I'm aware that not everyone likes the Unary quantifiers Π[_] etc., whereas I find them convenient shorthand. Will reconsider...

[jamesmckinna]

Regarding min? itself as a name:

• postfix ? to denote that this is a decision procedure (but maybe we should reserve such usage for functions returning Dec _ results?)
• min/μ by association with Kleene's minimisation operator.

[JacquesCarette]

findMinimum seems like a good name. searchForMin is another viable option. postfix ? to me always indicates Dec.

[jamesmckinna]

Thanks @MatthewDaggitt for the feedback:

• regarding lifting out these properties to a new module, that does seem like a good idea
• regarding naming/(use of) syntax, indeed there are lots of stylistic questions about the current version.

I'll move to DRAFT for the time being, and remove from v2.3, while I reconsider things.

[JacquesCarette]

All the code seems fine. Only issues are that things seem to have moved without a good reason to.

[JacquesCarette]

Why are these here? None of these are about a decidable predicate. I think these should be either in the main file or, at worst, a .Core version, but not here.

[JacquesCarette]

Likewise, there does not seem to be a good reason to move these here from the main file. This almost feels like a cut-and-paste error?

[jamesmckinna]

Hmmm... @JacquesCarette the code motion was in response to earlier review comments from @MatthewDaggitt , but maybe I misunderstood his intention. Nevertheless, the Quantification section is necessary for the subsequent decFinSubset and all?/any? definitions... so it seemed cognate to keep them together (esp. given the public re-export in Data.Fin.Properties...)

[JacquesCarette]

I had seen some of the conversation. This is why maybe a larger break up (Data.Fin.Properties.Quantification too?) might make more sense. Same with the Effectful stuff, it most definitely does not belong in .Properties.Decidable. The main code motion does make a lot of sense, it just has knock-on consequences.