Don't feel expert enough to comment in the details but I like it.

I should make it clear that the third item (no more unfolding for morphisms) is kind of a breaking change. I have no idea though how often people have been using ring_simplify in conjunction with a morphism ring out there, and even so, they can easily work around the change in a backward compatible way by using the postprocess option. Still, this is not satisfactory.

I believe we do some things with ring_simplify in https://github.com/mit-plv/fiat-crypto ; does this change break fiat-crypto?

I believe we do some things with ring_simplify in https://github.com/mit-plv/fiat-crypto ; does this change break fiat-crypto?

Possibly. For instance, in some cases where ring_simplify would have answered something like @exists Z (fun z : Z => z = z mod 17) 8 (Z_mod_mod 42 17), it will now answer @F.of_Z 17 42. I would say the new behavior is actually an improvement in your case too, but your mileage may vary.

@silene I've pushed a Travis build with your PR, maybe it is useful to see the impact?

https://travis-ci.org/ejgallego/coq/builds/198887029

Well, after having a look to https://travis-ci.org/ejgallego/coq/builds/198948362 , it seems this PR breaks Coquelicot and Flocq (and Compcert by transitivity) , I guess the author knows how to handle that :)

Do you know of any other development that runs in 8.6/8.7 and could be interesting to test?

it seems this PR breaks Coquelicot and Flocq

Regarding Flocq, the breakage gives a better view of the impact of this pull request, due to the number of different contributors. In particular, the following issues never occurred when converting the standard library:

• In various places, people have avoided typing an extra character by using R0 instead of 0%R (same for R1 and 1%R). They are no longer syntactically equal, so rewrite throws a fit whenever a rewriting lemma contains them.

• People tend to write rewrite Rmult_plus_distr_r, Rmult_1_l when they want to replace 2 * x with x + x. Again rewrite complains since 2 and 1 + 1 are no longer syntactically equal. Same issue when replacing 3 * x with x + 2 * x.

Interesting, thanks @silene . By the way, I see you seem to have pushed related changes to Flocq's master, this however breaks the automated build for both Coq 8.6 and trunk. Did you intend that?

If what you want is to have the ci scripts to point to a particular flocq branch for this PR, let me know and I'll add a Flocq overlay.

this however breaks the automated build for both Coq 8.6 and trunk

This was certainly not intended, especially since I successfully performed a full build of Flocq with Coq 8.6 before pushing (including Flocq's regression checks). Could you point me to these automated builds, so that I try to understand what went wrong?

I successfully performed a full build of Flocq with Coq 8.6 before pushing

Forget about that. I did indeed perform a full build, but the result was not successful. I am not quite sure how the failure went unnoticed. I will fix it.

Interestingly enough, most of the compilation failures came from misfeatures that this pull request intends to fix. For instance, there was a case of replace 1 with (/2 * 2) turning 2 into (/2 * 2 + /2 * 2), which was certainly not the intent of the user.

Does this PR still require fixes? Or can it be selected for the next round of merges?

No, it does not require any fix. So, at this point, it is mostly a question of deciding whether the benefits (faster decision procedures, more intuitive proofs, one parser/printer less) outweigh the issues (poor backward compatibility for low-level scripts).

Merging this patch (which looks great IMO) would break testing of flocq, compcert, and coquelicot. These are important packages. Guillaume, do you think such packages could be updated upstream as to be compatible with both 8.6 and 8.7 + this patch?

As for myself, I think that the benefits are strictly greater than the one issue of this PR, namely backward-compatibility. So I'm in favour of merging it.

Guillaume, do you think such packages could be updated upstream as to be compatible with both 8.6 and 8.7 + this patch?

For Coquelicot, it should be possible (though I won't have time to do that for the next two weeks). For Flocq, it is next to impossible, since Flocq comes with its own mechanism for "fixing" IZR (basically the same one as this pull request). Thus Flocq's mechanism intrinsically depends on the "broken" definition of IZR. So while the patch to Flocq is trivial (just replace the whole mechanism by a few identity functions), I can't think of a way to make Flocq compatible with both 8.6 and 8.7. Please someone implements #ifdef for Coq! Anyway, this would solve the issue only for the standalone version of Flocq, not the one included in CompCert. Now that dependencies are more easily handled thank to using opam, we should revisit the issue of Flocq being embedded in CompCert.

Please someone implements #ifdef for Coq!
+1 I've been thinking about this for a long time.

For now I guess you could use a poor's man version. There are two ways as far as I know:

• ship to different versions of a module containing the differences, and set the proper symlink at make time, this is what math-comp does.
• use #ifdef and call cpp at make time to generate the proper version of the file.

I may try the second approach to make HoTT 8.6/8.7 compatible.

ship two different versions of a module containing the differences, and set the proper symlink at make time, this is what math-comp does

Yes, that is what we have been using for the Coq library of Why3 too. Some of the files exist in three different versions (8.4, 8.5, and 8.6) and the Makefile machinery copies them around.

Please someone implements #ifdef for Coq!

Here is a messier but lighter-weight poor man's ifdef inside of Coq:

      Ltac ifdef' name x y :=
        tryif constr_eq name name then exact x else exact y.
      Definition F
        := ltac:(ifdef' x True False).
      Definition T
        := ltac:(ifdef' True True False).
      Print F. (* F = False *)
      Print T. (* T = True *)

Please someone implements #ifdef for Coq!

... which opportunately reminds me that the discussion on attributes for the 8.7 version has stalled...

Indeed, it would likely be more lightweight if coq_makefile2 would support cpp, together with seeding the files the proper version variables, etc...

Please someone implements #ifdef for Coq!

And which reminds me Coq 8.0 which had a "V7only [ vernac list ]." command :)

@ppedrot: there is no CEP for attributes, is there? If not, then maybe you could create a minimal one and the discussion could start again on the PR in the CEP repo (as this was the new workflow proposed by @silene).

At some point @aspiwack was mumbling something about writing such a CEP...

The basic idea was to have commands like Inductive [ attributes ] T ..., Definition [ attributes ] C ..., etc... Did I understand correctly?

The exact syntax has not been decided, but in the spirit yes. This would allow to define stuff on a Coq version basis, assuming we have some attribute version(...).

Would the syntax for tactics get attribute, whether it is on an individual basis, or at the level of a sentence?

Regarding attributes: I've got a draft proposal somewhere, indeed, as well as an incomplete prototype implementation. I'll try to unearth it next week.

I would very much be in favor of tactics taking attributes too, with some of them being generic and some being tactic-specific. That would avoid having tons of custom syntax: less syntax is better for learning...

That's starting to be a bit off-topic, but I'd personally like that attributes are attached to sentence rather than particular constructs, so that the syntax is uniform. For instance, something along the lines of:

#[version(8.5)]
Definition foo := 0.

This is a report of experience on porting the contributions AILS and Float to the new models for integer numbers in R.

[Note: AILS is an implementation of the Airborne Information for Lateral Spacing algorithm while Float is a floating-point library - maybe is it obsolete?]

In AILS and sometimes Float, there were typical breakages of the following form:

• 4*x does not rewrite anymore to 2*2*x by associatiativy
• 1+1 not any more the same as 2
• 1 syntactically distinct from R1
• 0 syntactically distinct from R0
• -1 syntactically distinct from Ropp R1
• for better compatibility, -0 should now be written -(0)

So, I guess this is expected and, at least for the two first cases, we cannot do a lot about it.

In Float specifically, the breakages are of different kinds:

• simpl on expressions of the form IZR local_constant are now blocked. This is fixable by using a unfold local_constant.
• simpl on expressions of the form IZR (Zpos p) are now blocked. This is fixable using typically a unfold IZR; rewrite <- INR_IPR.
  • Example: auto expects to apply the hint 0 <= INR (Pos.to_nat n) but finds 0 <= IZR (Z.pos n).
  • Note that in the case of ring, no changes would have been needed if ring had been able to recognize that IZR (Z.pos p) and INR (Pos.to_nat p) are the same. Don't know if it would be easy to do it.
• Another issue with ring is that ring_simplify on 0+1 now returns R1, while the scripts would have worked without needing a change if it had returned 1%R, since all lemmas involving the units in the library are now about 0%R and 1%R. Is there anything we can do for that? More generally, could it be possible to do so that we never have to see R0 and R1 any more?
• Finally, note that sometimes, a full block of several lines is not anymore necessary, which looks very good!

It's kind of unfortunate that this porting was not done while the PR was still open, isn't it? If the coq-contribs AILS and Float are still considered worth maintaining, they should be added to Travis CI. But you are suggesting yourself that maybe Float is obsolete. Was it the contrib which was strongly criticized as fundamentally incomplete by some people a while ago?

More generally, the question could be asked for all contribs. Which ones are still worth maintaining? Which ones are useful to people, and actually used? Could some of them find an external maintainer? ...

simpl on expressions of the form IZR local_constant are now blocked.

Yes, I have experienced it too. I feel like it is more of an issue with simpl than with IZR. For some reason, simpl is not applied to inner terms when outer terms are not simplifiable.

auto expects to apply the hint 0 <= INR (Pos.to_nat n) but finds 0 <= IZR (Z.pos n).

I wonder if we should add IZR_le to the hint database. This would automatically solve a bunch of goals.

if ring had been able to recognize that IZR (Z.pos p) and INR (Pos.to_nat p) are the same

No real difficulty but quite a bit of work. Since IZR (Z.pos p) and INR (Pos.to_nat p) are no longer convertible, the current reification mechanism of ring cannot handle them the same way. It would have to be extended the way it was for psatz and lra, which are able to recognize a lot of constants.

ring_simplify on 0+1 now returns R1

That surprises me. Part of the commits were especially meant to prevent that from happening. I will have to take a look at it.

More generally, could it be possible to do so that we never have to see R0 and R1 any more?

Theoretically, if none of your developments explicitly mention R0 and R1, they should only appear when you perform full-blown reduction à la vm_compute. Hopefully, no one ever calls vm_compute on a term of type R.

simpl on expressions of the form IZR local_constant are now blocked.

Yes, I have experienced it too. I feel like it is more of an issue with simpl than with IZR. For some reason, simpl is not applied to inner terms when outer terms are not simplifiable.

Looks unavoidable as this seems the standard way to work for simpl. It does not unfold a local definition if this does not contribute to a reduction.

This has by the way sometimes surprising consequences:

Lemma f (x := 1) : S x = x -> x + x = x * x.
intro; simpl.
(* S x = x -> S x = 1 *)

auto expects to apply the hint 0 <= INR (Pos.to_nat n) but finds 0 <= IZR (Z.pos n).

I wonder if we should add IZR_le to the hint database. This would automatically solve a bunch of goals.

Maybe worth to try, I don't know.

ring_simplify on 0+1 now returns R1

That surprises me. Part of the commits were especially meant to prevent that from happening. I will have to take a look at it.

Here is a reproducible example:

Require Import Reals Ring.
Goal (0+1=0)%R.
ring_simplify (0+1)%R.

if ring had been able to recognize that IZR (Z.pos p) and INR (Pos.to_nat p) are the same

No real difficulty but quite a bit of work. Since IZR (Z.pos p) and INR (Pos.to_nat p) are no longer convertible, the current reification mechanism of ring cannot handle them the same way. It would have to be extended the way it was for psatz and lra, which are able to recognize a lot of constants.

Could a pre-processor which rewrites one in the other relevant? An equivalent to zify for ring?

Here is a reproducible example

That is a funny one. It happens that 1 and -1 are hardcoded in the tactic. Since I had exercised the ring_simplify tactic only on non-trivial examples, I had missed this special case. Patch incoming.

Could a pre-processor which rewrites one in the other relevant? An equivalent to zify for ring?

That would be relevant. Yet, since ring is a reflective tactic and since this work can be done efficiently in a reflective setting, it would be a bit frustrating to have to fall back to rewriting here.

@Zimmi48: We need an infrastructure for benchmarking. We need a way to evaluate the impact of our changes on user developments. At best, this is the collection of all developments we are aware of, but reasonably, it can only be a representative subset of them.

Now, there is an inner contradiction in a benchmarking test: if we decide for a change of semantics, as we did for this PR, we must update the benchmarking suite otherwise it would not test anything further. This has been done for the packages tested on Travis, but of course there are many other packages available around which were not tested and which we could decide to test also. It is about finding an optimal compromise. In particular, we provided patches for the contributions tested on Travis so that we were still able to use the benchmarking suite (and, incidentally, this provides with a graceful service that we offer to the developers of these packages which we test).

Personally, as I said a couple of times, I believe that contributing to build a repository of mathematical and computer science results is important. This is a direction that Isabelle follows with AFP and that Mizar also follows with MML, a direction about which there was a seminar last October and which shows the interest of a community in this direction (especially the CICM community). Coq is not only a programming software, Coq has also a historical role to play as a tool to build formal mathematical knowledge and we should not lose this opportunity.

Also, when I'm testing AILS and Float, my objective is not to maintain them per se but to study from examples what should be done to improve the compatibility, what should be done so that the users don't have to waste time in maintaining their own contributions. Then, once they compile, they can in turn be reasonably reused for testing.

Float is not the contrib which was discussed some time ago. It was IEEE754. I'm mentioning Float as an example of package in the "contribs" subset which the authors may want to remove if they think e.g. that Flocq, developed by a group of authors non-disjoint from the ones of Float, can maybe seen as the natural upgrade of Float.

Personally, as I said a couple of times, I believe that contributing to build a repository of mathematical and computer science results is important. This is a direction that Isabelle follows with AFP and that Mizar also follows with MML, a direction about which there was a seminar last October and which shows the interest of a community in this direction (especially the CICM community). Coq is not only a programming software, Coq has also a historical role to play as a tool to build formal mathematical knowledge and we should not lose this opportunity.

You know I agree with you on that objective. This is also why I'm arguing for putting the standard library into its own repository. It could be the occasion to gather more contributions. For me, contribs do not correspond to the notion of a central repository. They are still external developments, even if they are maintained by the Coq developers.

Also, when I'm testing AILS and Float, my objective is not to maintain them per se but to study from examples what should be done to improve the compatibility, what should be done so that the users don't have to waste time in maintaining their own contributions. Then, once they compile, they can in turn be reasonably reused for testing.

Yes but then, why not include them into Travis? Your feedback would have been useful to improve the PR. It is still useful now, but earlier would have been better. And we would have got that feedback earlier if these contribs had been included in the Travis tests.

Float is not the contrib which was discussed some time ago. It was IEEE374. I'm mentioning Float as an example of package in the "contribs" subset which the authors may want to remove if they think e.g. that Flocq, developed by a group of authors non-disjoint from the ones of Float, can maybe seen as the natural upgrade of Float.

OK thanks! Indeed, this should be considered and decided by the authors themselves. Similarly, the author of GeoCoq asked for the removal of the older contrib for which it is a replacement (I don't know if that wish has been taken into account though.)

@Zimmi48: In general, I'm more on the side of thinking that it is unavoidable to have an experimentation phase for features, even more that we clearly have the responsiveness to deal with post-commit improvements. So, I'm not shocked by this PR having been merged, after having taken into account the elements of the PR discussion, in a state which looks to me reasonable.

And I'm fine with being the one who looks at the contribs compatibility.

Flocq, developed by a group of authors non-disjoint from the ones of Float, can maybe seen as the natural upgrade of Float

To be clear, the natural upgrade of Float (15 years old) is PFF (10 years old). Note that it might be that the content of the contrib is actually PFF and it just happens that the contrib was never renamed; I haven't checked. Flocq is meant to absorb PFF in the long run, but it is not there yet. In fact, Flocq contains some .v files that actually require PFF; they are not compiled by default to avoid the dependency.

@silene: the version we have contains files which are the light grey ones at the pff page (up to AllFloat.v).

So, what are your projects with the PFF extension of Float? If the project is that Flocq absorbs
PFF in the long run, and if Flocq actually already morally depends on PFF, wouldn't it make more sense that PFF is integrated to Flocq now, even if in the long run some modifications are brought to PFF?

Of course, this is a very naive question since I'm unaware of the technical and material issues relative to such a move. So, I apologize for this probable naivety.

the version we have contains files which are the light grey ones at the pff page

So it is indeed the Float part only.

So, what are your projects with the PFF extension of Float?

It is not clear yet. We certainly don't want to expose the (outdated) interface of Float/PFF, but some of the more complicated results are only available in PFF. As a rule of thumb, all the facts proved in the light grey files (that is, Float) have been made obsolete by Flocq, but some of the higher-level files of PFF (e.g. FmaErrApprox) still contain original (and sufficiently interesting) results.

So since Float has been made obsolete and Flocq is tested in Travis, do you think Float should be removed from the contribs or does it still make sense to keep it?

A few more comments about the impact of this PR on compatibilitity.

• That simpl on expressions of the form IZR (Zpos p) or IZR (Zneg p) are now blocked remains one of the important cause of incompatibilities. Is there something to improve here? In particular, it is not fully clear to me what are the situations when we want IZR to be simpl never and when we would like instead it to reduce a bit. @silene, do you know more?
• There are still a few lemmas which auto cannot solve anymore. A typical one is 0 <= 2 formerly proved by Rlt_le, Rle_lt_0_plus_1, Rlt_le, Rlt_0_1, but which now fails because Rle_lt_0_plus_1 produces R1 while Rlt_0_1 expects 1%R. Should Rle_lt_0_plus_1 mention 1%R instead?

That simpl on expressions of the form IZR (Zpos p) or IZR (Zneg p) are now blocked remains one of the important cause of incompatibilities.

There might be a misunderstanding there. The cause of the incompatibility is not that IZR no longer reduces, it is that it is no longer convertible to INR (except for 0, 1, and 2). I cannot think of a single situation where reducing IZR is actually interesting, even for compatibility purpose.

Should Rle_lt_0_plus_1 mention 1%R instead?

Does it not?

Lemma Rle_lt_0_plus_1 : forall r, 0 <= r -> 0 < r + 1.

Anyway, as I said, a goal like 0 <= 2 is meant to be solved by IZR_le rather than a long sequence of lemmas. Unfortunately, I have not yet found time to check what would be broken by adding this lemma to the hint database of auto.

@silene: Looks like I'm going round in circles. I'm hoping a strict compatility of simpl in IZR (Z.neg x) returning Ropp (INR (Pos.to_nat x)), which is hopeless. The workaround is unfold IZR; rewrite <- INR_IPR and strict compatibility seems unattainable.

About Rle_lt_0_plus_1, I indeed spoke too quickly, it is applying the lemma which exposes the R1 after unfolding 2%R. So, nothing really new since my previous message.

Hi, I noticed another example of unexpected unfolding of real constants using the Maple mode which is relying on low-level commands of the ring/field plugin. I could not find though a way to get a similar behavior with the high-level tactics field_simplify or ring_simplify.

Require Import Reals.
Ltac f x := constr:(FEc 2%Z).
Goal True.
prove_with_field ltac:(f) (1+1)%R.
(* (R1 + R1)%R = (R1 + R1)%R -> True *)

This is related to protect_fv which normalizes the constants, but I'm unsure how to fix that (don't know how to adapt the ring_simplify fix from d6ced63).

don't know how to adapt the ring_simplify fix from d6ced63

From a quick glance at the code, it seems like the function that needs protection is FEeval. So the trick is to look at the commit message of ddbc383. The phi argument occurs at position 10, so 10 has to be moved from Eval to Rec, as was done in d6ced63. I will try later today whether it breaks anything.

Seems indeed to fix the problem I observed. Thanks very much!

For compatibility purposes, I'm trying to transform a real constant into an expression made only of Rplus, Rmult, R0, R1, Rdiv, Ropp. Don't know if this is the best idea, but my first try is to prove lemmas such as forall x, IZR (Zpos (xO x)) = 2 * IZR (Zpos x) which do not seem to exist. There is an optimizing function IPR_2 which saves a trailing * R1 as we did before. Do I consider that this optimization is important, even if the expansion of constants is now supposingly to be exceptional and prove a sublemma IPR_2 x = 2 * IPR x?

Alternatively, that would be cool to have some set IZR simpl nomatch in tac tacticielle.

For compatibility purposes, I'm trying to transform a real constant into an expression made only of

What I did for fourier is just compute [IZR IPR IPR_2]. Since the normal form of real constants has not changed between 8.6 and trunk, I don't see the point of having lemmas, reducing should be enough.

@silene, a comment not to forget: the chapter describing notations still mentions the old encoding of reals.

Oh! I didn't even know it was documented in the reference manual. Will do.