Skip to content
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

Tutorial Equations: well-founded recursion #8

Merged
merged 37 commits into from
Jun 21, 2024
Merged

Conversation

thomas-lamiaux
Copy link
Collaborator

@thomas-lamiaux thomas-lamiaux commented May 14, 2024

A tutorial explaining how to use Equations to define functions by well-founded recursion, and how to reason about such functions.

There is left to :

  • Write some text in the intro to well-founded recursion, section 1.1
  • Solve the issues with the ackerman function, section 1.2
  • Better text for definition using obligations
  • Find a good examples for subterm relation, section 2.1

@thomas-lamiaux thomas-lamiaux marked this pull request as draft May 14, 2024 00:53
@thomas-lamiaux thomas-lamiaux marked this pull request as ready for review May 18, 2024 00:51
@thomas-lamiaux
Copy link
Collaborator Author

The tutorial is now ready to be reviewed. It :

  1. add a new tutorial
  2. adds a paragraph to CONTRIBUTING about discussing what does not work
  3. makes marginal modifications to Tutorial_Equations_basics and README

src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
@thomas-lamiaux thomas-lamiaux mentioned this pull request May 21, 2024
6 tasks
Copy link
Contributor

@MevenBertrand MevenBertrand left a comment

Choose a reason for hiding this comment

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

I've found this tuto a bit more messy than the previous one. I feel my main issues were the following.

There is a lot of knowledge which is not specifically about well-founded induction, but rather about how to generally go about the obligation mechanism. They are scattered through the tutorial as things go, which makes them not so visible. Maybe having a self-contained presentation of this mechanism (Equation vs Equations?, printing and (locally) changing the obligation tactic, printing the obligations with Obligations, being careful that no obligations are left, etc.), either in this tutorial, in the one of Equations' basics, or a self-contained one.

I found the presentation of well-founded induction unclear: the first example, last, is a very specific limitation of the guard-checker of Coq, but it is really at the border, and thus not very enlightening. The examples of nubBy or gcd, which require non-trivial reasoning, are more to the point. Ackerman is nice to introduce lexical ordering, but I feel like this can come slightly later. I would rather start by using a measure with the well-founded order lt on nat (which btw Equation picks by default if you write only by wf (length l)), and introduce lexical order in a second time as a more advanced example. Also, I'm not sure a reader would be able to understand the current 1.1 if they do not already have heard about proofs of termination for functions, well-founded orders, etc.

I know it was a frustrating experience in the writing of the tutorial, and that it's good to give users ways to circumvent issues when they pop up rather than pretending everything is fine, but I feel a lot of cognitive load in 1.2 is spent of funelim and rewrite going wrong. This somehow deflects from the "main point" of the tutorial into subtle, more advanced issues.

Also, a few suggestions on more things that might be useful to have in this tutorial:

  • usage of map and friends which remember which list an element was in (something similar in spirit to the inspect pattern, see for instance here and here)
  • using the database [WellFounded], possibly in combination with Derive to obtain the subterm relation and an automatic proof that it is well-founded. Very useful for well-founded induction which is more or less structural but more complicated than what the guard detects (for instance, if one want to do the last example without resorting to length but directly by a well-founded order on lists)

It's a long review with a lot of comments, but I must say this tuto is still a nice step in the right direction of making Equations more accessible!

src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
@thomas-lamiaux
Copy link
Collaborator Author

thomas-lamiaux commented May 28, 2024

The comment's are good and I'll look into them. An issue I have is that I lack simple examples. Would you have some to share @MevenBertrand ? In particular, would you have a good example for

using the database [WellFounded], possibly in combination with Derive to obtain the subterm relation

Co-authored-by: Meven Lennon-Bertrand <[email protected]>
@thomas-lamiaux
Copy link
Collaborator Author

Also the issue with ack in 1.2 is that it is supposed to be basic and yet it doesn't work as you would expect.
Though to make it clearer I can move it to a section 3.

@MevenBertrand
Copy link
Contributor

For your first question: maybe you can show how to do last a second time, but using subterm as the order rather lt + length? Otherwise, I don't have an example on the top of my head, but I will think about one.

Re: ack, I understand your issue, and I'm annoyingly not sure how to make it more readable (apart from having fixes merged upstream in Equations, it seems Matthieu is on it?). Maybe the solution would be again to have an alternative example which Equations does not choke on? (Again, I don't have one right now, but I can think about it.)

-> Seperate section 1 in two sections "Intro to wf" and "wf and Equations"
-> Remove the last example from the file, and ack from 1.2
-> Remove content that is now in tuto obligations
@thomas-lamiaux
Copy link
Collaborator Author

@MevenBertrand could you review the file tutorial about obligations and tell me if it is looks good to you ?
Btw, I could also use help for the 2.2 part

Copy link
Contributor

@MevenBertrand MevenBertrand left a comment

Choose a reason for hiding this comment

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

I only looked at the obligations tutorial, lgtm up to some minor polishing. And I think it is much better to factor this out like it is done now.


Therefore, we would much rather like to build our terms using the proof mode.
This is exactly what [Program] and obligations enables us to do.
At every point in a definition, it enables us:
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
At every point in a definition, it enables us:
At every point in a definition, it allows us to:

Copy link
Contributor

Choose a reason for hiding this comment

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

The structure of the list is a bit strange, the "allow to" really only applies to the first item. Maybe try to rephrase?

src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_Obligations.v Outdated Show resolved Hide resolved
Co-authored-by: Meven Lennon-Bertrand <[email protected]>
In the following, we assume basic knowledge of obligations as discussed
in the (short) tutorial Equations: obligations.

** 2.1 Using a size argument
Copy link

Choose a reason for hiding this comment

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

Instead of framing the 2.1 and 2.2 examples as "size vs measure" I think it would be clearer to only talk about "measure", then 2.1 gives a simple example (where the measure depends on one argument), and 2.2 shows that the measure can depend on all of the arguments.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was thinking about it and hesitating. I'll do that, thanks.

@thomas-lamiaux
Copy link
Collaborator Author

Ready to be reviewed again

Copy link
Contributor

@MevenBertrand MevenBertrand left a comment

Choose a reason for hiding this comment

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

Looks good to me! (Up to a big pass of clean-ups). Things are probably not perfect, but le mieux est l'ennemi du bien ;)

src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
the obligation [sizeRT l < 1 + list_sum (map sizeRT lt0)] corresponding to
the case where [lt := l :: _].
This is obviously true, but we are stuck trying to prove it as we do not
remember that [l] in in [lt]:
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
remember that [l] in in [lt]:
remember that [l] is in [lt]:

Proof.
simp sizeRT.
(* What to do know ? We have forgotten that x is in l,
and hence that sizeRT l < 1 + list_sum (map sizeRT l0) *)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
and hence that sizeRT l < 1 + list_sum (map sizeRT l0) *)
and hence that sizeRT l < 1 + list_sum (map sizeRT lt) *)

src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Show resolved Hide resolved
thomas-lamiaux and others added 2 commits June 19, 2024 14:36
Co-authored-by: Meven Lennon-Bertrand <[email protected]>
Co-authored-by: Meven Lennon-Bertrand <[email protected]>
Copy link
Collaborator Author

@thomas-lamiaux thomas-lamiaux left a comment

Choose a reason for hiding this comment

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

Thanks for looking at it

Hence, when there is no obligation proof mode is open for nothing, and
has to be closed by hand using [Qed] or [Defined] as it can be seen below.
As it is easy to forget, a warning is raised.
*)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So I have asked and it does enable a better control, btw that is one of the advantage of Next obligation compared to Equation?, but I would rather not talk about it as it is really advanced.

src/Tutorial_Equations_wf.v Show resolved Hide resolved
src/Tutorial_Equations_wf.v Show resolved Hide resolved
src/Tutorial_Equations_wf.v Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved

(** Knowing that the previous booleans have been [false] enables us to prove
that [R] is well-founded when combined with [h].
We omit the proof here because it is a bit long, and not very interesting
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I am not what is the interrest here. To me it was showing of to declare and use a wf, not how to prove it is wf

@thomas-lamiaux
Copy link
Collaborator Author

@MevenBertrand could you review the last commit. If all is good for you I'll merge.
Btw if you hadn't noticed there is now automatic type checking and deployment.

Copy link
Contributor

@MevenBertrand MevenBertrand left a comment

Choose a reason for hiding this comment

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

🚀

src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
src/Tutorial_Equations_wf.v Outdated Show resolved Hide resolved
thomas-lamiaux and others added 2 commits June 21, 2024 14:04
Co-authored-by: Meven Lennon-Bertrand <[email protected]>
Co-authored-by: Meven Lennon-Bertrand <[email protected]>
@thomas-lamiaux thomas-lamiaux merged commit 0e881e9 into main Jun 21, 2024
2 checks passed
@thomas-lamiaux thomas-lamiaux deleted the tuto-equations-wf branch June 21, 2024 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

4 participants