-
Notifications
You must be signed in to change notification settings - Fork 700
Modify name of induction scheme hypotheses #20813
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
Modify name of induction scheme hypotheses #20813
Conversation
|
@coqbot run full ci |
fea4334 to
76dcadd
Compare
|
@coqbot run full ci |
|
In addition to overlays, this will also need a changelog. |
ppedrot
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks desirable to me, both codewise and in terms of feature.
…generated schemes)
| (srefl : P a (srefl a)) (a0 : A) (s : seq a a0) => | ||
| match s :> seq a a0 as s0 in (seq _ a1) return (P a1 s0) with | ||
| | srefl _ => f | ||
| | srefl _ => srefl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Expressions like this look confusing to me, with two of the srefls being constructors, and the other two being the argument (IIUC). It seems to me that this makes it harder for the reader to quickly see what is going on, especially if the expression appears further from the argument list. Is this really an improvement? What about calling the argument something like srefl' instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was made partially with the intent of using those names to generate goal names (see #20809), and in that use case it would not make much sense to write [true']: instead of [true]: as a goal selector.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe true_case then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd argue this is a printer issue, we should disambiguate the constructor names when there are bound variables that clash with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #20824 for a fix that makes this readable.
…generated schemes)
…nerated schemes)
0327afd to
0cc933b
Compare
|
@ppedrot this PR is ready for a full CI run |
|
@coqbot run full ci |
|
(CI failure looks unrelated, also fails on master) |
|
This got a green light at the Rocq call, so I guess we can just @coqbot merge now |
|
@ppedrot: Please take care of the following overlays:
|
…ciple-cases Adapt to rocq-prover/rocq#20813 (Update default hypothesis name in generated schemes)
…nciple-cases Adapt to rocq-prover/rocq#20813 (Update default hypothesese names in generated schemes)
…0824 Reviewed-by: ppedrot Co-authored-by: ppedrot <[email protected]>
Moves away from generated names
f,f0, etc., and instead uses the constructor names for the hypotheses of the induction scheme.Overlays: