Skip to content

[ add ] Relation.Nullary.Decidable.dec-yes-recompute #2738

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

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

jamesmckinna
Copy link
Contributor

@jamesmckinna jamesmckinna commented Jun 20, 2025

This PR sharpens the type of Relation.Nullary.Decidable.dec-yes by supplying an explicit existential witness:

  • dec-yes-recompute weakens the hypothesis to allow irrelevant argument .(a : A)
  • by witnessing the existential with recompute a? a
  • dec-yes then follows immediately.

It introduces two new lemmas:

  • Relation.Nullary.Recomputable.recompute-irrelevant-id: for propositionally irrelevant A, recompute is the identity
  • Relation.Nullary.Decidable.Core.recompute-irrelevant-id, encapsulating the above

UPDATED:

  • refactors Relation.Nullary.Recomputable to lift definitions and basic properties out into Relation.Nullary.Recomputable.Core.

Copy link
Contributor

@JacquesCarette JacquesCarette left a comment

Choose a reason for hiding this comment

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

As this is likely a rather obscure bit of functionality with few users, I don't mind the name churn.

@jamesmckinna
Copy link
Contributor Author

jamesmckinna commented Jun 21, 2025

As this is likely a rather obscure bit of functionality with few users, I don't mind the name churn.

Well, I'm not thrilled by the name churn, but I wasn't quite prepared to just grab the old name and give it the new type... UPDATED but in a breaking v3.0 change, I might be tempted to rethink all the various names of these highly niche lemmas?

As it is, and seeing the single downstream use of the new construct, I think it can even be avoided altogether (or rather: it is still useful, but localised to its use as a step on a better path to dec-yes-irr, which is the enabling technology in Relation.Binary.PropositionalEquality for leveraging UIP for DecidableEquality...)... see #2740

UPDATED: the use of the new lemma in Data.Fin.Permutation is superseded by the changes in #2740 but I think that these two PRs are orthogonal, modulo rebasing, so I've removed the blocked-by-issue label. Think that this would be good to merge now, unless the right thing to do is revert the knock-on changes to Data.Fin.Permutation?

@jamesmckinna jamesmckinna added status: blocked-by-issue Progress on this issue or PR is blocked by another issue. and removed status: blocked-by-issue Progress on this issue or PR is blocked by another issue. labels Jun 21, 2025
Copy link
Contributor

@MatthewDaggitt MatthewDaggitt left a comment

Choose a reason for hiding this comment

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

Otherwise looks good!

@jamesmckinna
Copy link
Contributor Author

jamesmckinna commented Jun 25, 2025

I suppose that the last step would be to make the breaking change, and simply give dec-yes the new type of dec-yes-recompute... but then we'd be bumping to v3.0 rather than v2.3. Still, worth considering downstream? NB. There are now no uses of dec-yes elsewhere in stdlib.

@MatthewDaggitt
Copy link
Contributor

How about leaving the existing definition as is?

@jamesmckinna
Copy link
Contributor Author

Latest commits should fix things as agreed 2025-06-25.

@jamesmckinna jamesmckinna changed the title [ refactor ] deprecate Relation.Nullary.Decidable.dec-yes via [ add ] Relation.Nullary.Decidable.dec-yes-recompute [ add ] Relation.Nullary.Decidable.dec-yes-recompute Jun 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants