Introduce `NonZero` to `Data.Fin` as well

[MatthewDaggitt]

Just noticed we have similar constructor issues in various Fin operations and proofs.

[jamesmckinna]

Oh? I found only pred< in Data.Fin.Properties, and that seems used nowhere else...
EDITED: and ignore that branch... I failed to separate it from all the other commits on pr1698-extended. D'oh.

[jamesmckinna]

Interesting corridor discussion. My eyes are somewhat more open about this now.

[MatthewDaggitt]

In summary we want to avoid arguments of the form Fin (suc n) as that makes it very difficult to use the functions when the Fin index is known to be non-zero but is not of that form, e.g. Fin (n !)...

[jamesmckinna]

Yes, OK. In the first instance, though, moving to .{{_ : NonZero n}} arguments on indices does/would generate a lot of explicit use/mention of pred... maybe that is simply a pain for the library (and its developers) but better for downstream clients? is that an argument for a (more?) disciplined separation of public/private interfaces to modules... with the private interfaces being more dependently-typed/constructor-form index-aware, with the public interface being more destructor-form index focused? In miniature, I guess that was part of the #1709 discussion, with Data.Nat.Properties.Core.≤-pred being precisely such a form...

Sorry for not having had a more nuanced sense of these things until our discussion yesterday. Hmmm.

[MatthewDaggitt]

Yes it would mean more uses of pred, and I agree with your analysis about the cost/gain benefits for devs vs users. One thing to say is that it also makes the proofs slightly harder to read for the users... but I think the gain is usability outweighs that.

As for the more general point, yes that sounds reasonable. Although unfortunately we have no real (enforced) notion of private/public interfaces...

[jamesmckinna]

Worker/wrapper idiom: I'd suggest leaving in the old 'worker' proofs then, and only add new ones expressed in terms ofpred... not least because these latter will most likely be easy 'wrapper's around the former... and then any client module importing these can decide which they need/prefer to use?

[jamesmckinna]

How's this one going?
I've opened a branch on my repo and done some initial experiments with introducing wrapper functions...
... but there is clearly huge client dependency in the library on Data.Fin.* so this might be a big job.
I'll push the beginnings with a view to discussing this and then perhaps moving forward towards a PR on this.

[jamesmckinna]

Hmm. See this branch for the beginnings:

• systematically introduce {{NonZero n}}-qualified wrappers prefixed by NZ for any worker operations which are not homogeneous/uniform in the telescope {n}(i : Fin n), with generic definition NZ<wrapper> {n = suc n} = <worker> (with some interesting exceptions, where the constraints can be further simplified);
• additional infrastructure in Data.Fin.Base: a uniform zero and uniform suc operation, as well as a lot of other stuff besides, in the same idiom as above.

What isn't there yet are:

• operations in Data.Vec.Functional waiting for the -relative issue Use -local consistently for properties #626/PR Resolves issue #509 and resolves issue #626 #1822 to be resolved;
• further deployment of the NZ operations in downstream/client modules (how far can this be pushed? where? why?)
  @MatthewDaggitt would you take a look before I open a PR, to see if this is the kind of thing you had in mind?

Oh... and the CHANGELOG...

[MatthewDaggitt]

Looks good, a PR along those lines would be welcome! But I was actually thinking of making the changes to the original operators rather than just adding the NZ ones. It's a pretty backwards compatible change, and should drastically increase usability!