rocq-prover / rocq-prover/platform-docs
Chaining tactics issues
Open
Nobody has claimed this yet.
documentation
Improvements
- Dominant language
- Rocq Prover
- Stars
- 26
- Forks
- 25
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 1
Description
Some thoughts I will try to address shortly, but this can start a discussion.
This follows the merging of #66.
- There is no benefit in using
sumandpropinTypeinstead of\/and/\inProp. Depending on their background, some users can be very surprised that we build functions this way. The same apply to the second part whereA,B, ... could perfectly live inProp.
Even with a background in type theory, this is not, imho, a case where a proof is much simpler than the hand-written term:
Definition foo (x : A * (B + C + D)) : A * B + A * C + A * D :=
let (a, bcd) := x in
match bcd with
| inl bc => match bc with
| inl b => inl (inl (a, b))
| inr c => inl (inr (a, c))
end
| inr d => inr (a, d)
end.
- Is there an agreement on using
Goalinstead ofLemma foo1,Lemma foo2? I don't see a strong benefit except being able to give multiple proofs without providing new names for lemmas. - We should emphasize that both
tryandrepeatbreak the "fail fast" principle and may make some proofs very hard to maintain. - Some consistency in the proof scripts style could be discussed (bullets, spaces around
:or;, spaces inside brackets, ...) - The fact that chaining and tactics like assumption can free us from naming explicitly assumptions could be discussed here.
- We need to add examples with
[tac1 | tac2.. | tacn]. - The word "tactical" is not used, is it a choice?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the material changed in #66 and the current chaining tactics documentation. Resolve the seven listed questions—notation, Goal usage, try/repeat guidance, style, unnamed assumptions, bracketed alternatives, and “tactical” terminology—and add the requested examples. Done means the documentation reflects an agreed scope and includes the requested examples.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100