-
Notifications
You must be signed in to change notification settings - Fork 6
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
Hard to fix Stdlib arithmetic deprecations in 8.18 breaking many projects in 8.19 #7
Comments
I'm sorry this caused you some inconveniences. Indeed
However, I certainly don't want to criticize @olaure01 and @SkySkimmer too much; the hints were already very useful and this was already quite a huge work. And of course, I'm also to blame since in the end I removed these files. |
@Villetaneuse to be clear, this was not at all about distributing blame, but instead about flagging up our hurdles and starting an inquiry into what we can do going forward. In theory, "new" lemmas like In any case it makes sense to me to try to list such new "compatibility" lemmas to introduce for addition to 8.20 and then do a PR with them. |
Hi, Pierre,
I would be pleased to share my experience about deprecated lemmas :
- many of them could be solved by a simple systematic string replacement (e.g. plus -> add, minus -> sub, …)
- some others required to interactively change the direction of rewrite tactics (or replace an apply with a rewrite, …).
- same issue with changes in the order of hypotheses in a lemma: we have to re-edit the script.
- in big scripts (like in the goedel project) updating long tactics which contains several `repeat`s was a nightmare.
- in the `le_plus_minus_r` example, the suggested hint looks reasonable, but the issue appeared inside a complex term composed of arithmetic operations, where the preliminary use of `add_comm` was not immediate to instantiate (the posted mwe was only a mwe).
In this last example, I ended up by creating a sub-directory undeprecate/ to ensure compatibility with my scripts without getting warnings.
I’m not sure it’s a good solution …
… Le 3 janv. 2024 à 14:47, Pierre Rousselin ***@***.***> a écrit :
I'm sorry this caused you some inconveniences. Indeed Minus.le_plus_minus_r was one of the lemmas without direct translations and caused me some problems too. Others on the top of my head are all the equivalences (e.g. Nat.succ_lt_mono).
There are 3 possible discussions happening here :
• how to fix this problem this time:
I think rewrite (fun n => Nat.add_comm n (_ - n)), Nat.sub_add. should handle most cases.
• should we identify missing lemmas to include in 8.20? In this case, this would probably be something like add_sub_r (the idea is that plus is the symbol and add is the operation). I'd be happy to be part of this effort if there is consensus.
• how to handle better deprecated lemmas? I agree on the need to have better ways to handle this.
However, I certainly don't want to criticize @olaure01 and @SkySkimmer too much; the hints were already very useful and this was already quite a huge work. And of course, I'm also to blame since in the end I removed these files.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Probably not for 8.19.0 but we could do a rapid 8.19.1. |
Here is another example of an inconvenient deprecation replacement in 8.18: Require Import Arith Lia.
Goal forall n m, S n <= m -> S n - S m = 0.
intros n m Hn.
rewrite not_le_minus_0.
(*
Warning: Notation not_le_minus_0 is deprecated since 8.16.
The Arith.Minus file is obsolete. Use Nat.sub_0_le (together with Nat.lt_nge and Nat.lt_le_incl) instead.
[deprecated-syntactic-definition-since-8.16,deprecated-since-8.16,deprecated-syntactic-definition,deprecated,default]
*)
- reflexivity.
- lia.
Qed. Just replacing |
I went through a lot of commits fixing deprecations, notably coq-community/coqtail-math@fcf495c coq-community/coq-art@c41affd. Here is my definitive list of the deprecated lemmas that take "too much" effort fix:
If we have agreement this is a good idea, I can make a PR reintroducing these as close to verbatim as possible under appropriate new names |
Are you sure about I am very busy until Wednesday, but then I'll start working on it with you. I just created this thread on zulip to coordinate work. |
The background on |
Aren't |
It seems that what I was looking for was However, these lemmas were not mentioned in the deprecation message, and it's unfortunate that So I guess |
I noticed also a small issue in Lists.List
The deprecation message for `app_ass` is `use app_assoc instead`, which doesn’t mention that we have to change the direction in a rewrite.
It may cause an error in a simple rewriting but, worse, rewrite the bad sub-term or loop inside a complex tactic call.
Btw, a deprecation message may appear several times for the same term (e.g. `rewrite app_ass`). Is it a known fact?
… Le 6 janv. 2024 à 23:20, Karl Palmskog ***@***.***> a écrit :
It seems that what I was looking for was Even_EvenT and Odd_OddT as shown in this commit: ***@***.***
However, these lemmas were not mentioned in the deprecation message, and it's unfortunate that EvenT doesn't use Nat.double like even_2n did before it...
So I guess even_2n and odd_S2n can be dropped from my list of additions, but I still think the deprecation message should be changed in 8.18.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I agree the I believe the repetition of deprecation messages is a known problem, I think it has to do with how elaboration of syntax is currently done in different phases. |
I think this has been fixed. On which version is it observed? |
The last time I observed it is with Coq 8.18.0
Require Import List.
Import ListNotations.
Goal forall l l1 l2: list nat, ((0::l)++l1)++l2 <> nil.
intros l l1 l2.
rewrite app_ass.
(*
Warning: Notation app_ass is deprecated since 8.18. Use app_assoc instead.
[deprecated-syntactic-definition-since-8.18,deprecated-since-8.18,deprecated-syntactic-definition,deprecated,default]
Warning: Notation app_ass is deprecated since 8.18. Use app_assoc instead.
[deprecated-syntactic-definition-since-8.18,deprecated-since-8.18,deprecated-syntactic-definition,deprecated,default]
Warning: Notation app_ass is deprecated since 8.18. Use app_assoc instead.
[deprecated-syntactic-definition-since-8.18,deprecated-since-8.18,deprecated-syntactic-definition,deprecated,default]
*)
Undo.
Fail rewrite app_assoc.
rewrite <- app_assoc.
discriminate.
Qed.
… Le 7 janv. 2024 à 10:43, Pierre Rousselin ***@***.***> a écrit :
Btw
|
There is already this issue. |
Some time has passed (sorry, I'm slow...) and now I understand better the |
@Villetaneuse I have no updates, I think we have fixed all or most projects in Coq-community, so the "final" list of problematic removed lemmas is:
|
Thanks! |
Description of the problem
Pierre Castéran and I have recently tried to fix many Stdlib arithmetic deprecation warnings in Coq 8.18 to avoid projects breaking in 8.19 due to coq/coq#18164. However, we have determined that some, specifically those related to
Nat.add_sub
andNat.sub_add
require significant work and are thus likely to break many projects forever. The following example is due to @Casteran:We believe Stdlib maintainers and release managers should seriously consider ensuring deprecated/removed lemmas requiring a combination of
Nat.sub_add
/Nat.add_sub
andNat.add_comm
likele_plus_minus_r
are added verbatim underNat
, e.g.,Nat.le_plus_minus_r
, cc: @SkySkimmer @olaure01If coq/coq#18355 was implemented, the severity of this problem would be significantly reduced.
Coq Version
Deprecations show up in 8.18.0 and projects break in 8.19+rc1.
The text was updated successfully, but these errors were encountered: