Skip to content

memb and nodupb in ListDec.v #132

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Villetaneuse
Copy link
Contributor

@Villetaneuse Villetaneuse commented Apr 14, 2025

Still a draft, request for comments

  • reflect_iff_false in Bool/Bool.v to help work with reflect in vanilla
  • memb and nodupb in List.dec with reflection principles (some weaker, again to help with vanilla apply) : membP, memb_In, memb_nIn, nodupbP, nodupb_NoDup, nodupb_nNoDup

What I'm not so sure about :

  • the whole thing is parameterized by a proof named dec of strong decidability of equality (in sumbool), instead of eqb together with a reflection principle of eqb (maybe bundled in an eqType, as in mathcomp)
  • I know, these are equivalent, via bool_of_sumbool and sumbool_of_bool, but still it encourages to use a, maybe strange and changing, proof of decidability in definitions, instead of a nice boolean function

But, if we change things this way :

  • Maybe take eqType and most of seq from mathcomp in StdLib ? Or part of them ? In different files ? And keep ListDec (at least serveral versions) frozen for compatibility before removal ?

Fixes / closes #????

  • Added changelog.
  • Added / updated documentation.
  • Opened overlay pull requests.

Still a draft, request for comments

- reflect_iff_false in Bool/Bool.v to help work with reflect in vanilla
- memb and nodupb in List.dec with reflection principles (some weaker,
  again to help with vanilla apply) :
  membP, memb_In, memb_nIn, nodupbP, nodupb_NoDup, nodupb_nNoDup

What I'm not so sure about :
- the whole thing is parameterized by a proof named `dec` of strong
  decidability of equality (in sumbool), instead of eqb together with a
  reflection principle of eqb (maybe write in an eqType, as in mathcomp)
- I know, these are equivalent, via bool_of_sumbool and sumbool_of_bool,
  but still it encourages to use a, maybe strange and changing, proof of
  decidability in definitions, instead of a nice boolean function

But, if we change things this way :
- Maybe take eqType and most of seq from mathcomp in StdLib ? Or part of
  them ? In different files ? And keep ListDec (at least serveral
  versions) frozen for compatibility before removal ?
@ppedrot
Copy link
Member

ppedrot commented Apr 14, 2025

I think that this goes the right direction. The boolean decider should probably be made fully boolean, i.e. depend on a boolean function rather than a predicate decider. The full boolean version is a strict subtype of the other, so it's more expressive, and it furthermore ensures a strict stratification between ugly tactic-generated proofs and computational parts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants