Is there any reason not to make iff a record and define projections for it?

Same question as Jason. I often write the following kind of code (e.g. about 150 occurrences in Interval)

rewrite (proj1 (foo ...))

and, if there are no projections, it would become

rewrite (let (p1,_) := foo ... in p1)

I can obviously define my own projections to avoid this noise. But if every user does, they might as well be part of the standard library.

Or perhaps it is another case where you expect that the coercion to and takes over?

@jason,silene: I don't see particular objections at defining iff as a record with its own projections.
@silene: Yes, it is to deal with this situation that I introduced a coercion from iff to and.

Having it as a record would make it a tiny bit easier to eventually turn on primitive projections, I think

If the porting of the standard library is to be believed, then this is a very welcome change: pretty much every single line changed is now shorter.

Nevertheless, and to echo previous comments, I would prefer that there is no coercion to and, and if iff was a record instead. It would make porting a little bit harder, but overall it would probably be beneficial. By the way, is there any reason not to make iff a primitive record right away?

Perhaps there should be coercions in both directions in the compatibility file, and no coercions in the standard library?

I don't see how to mainly keep the compatibility without a coercion, but having a coercion in the compat file and let users require this file (or add explicitly the coercion themselves) is also ok to me. Would it be an ok migration strategy for @silene if this no-coercion compat-file-based strategy is adopted?

The compilation of this PR fails already on the test-suite with 5 errors.

The compatibility file is fine when you need to compile an old library with a recent Coq. But, when you need to compile a recent library with both an old (8.5) and a recent Coq (8.6), it is no longer suitable because it imposes an all-or-nothing choice which gets you stuck in the past. But do not worry about me, I will ship my own compat file that contains only the iff coercions and no other compatibility features.

My current position on this problem: This is a library issue worth to be improved but we need smart ideas to improve compatibility (or at least a clear support from users to accept the incompatiblity).

Wouldn't be this issue the perfect example for trying @Zimmi48 's suggestion of versioning the std library ?

@ejgallego: yes, that may be attempted. Don't know what others think...

I would think that versioning the library would be the solution here indeed and BTW this is what Michael Soegtop is asking for.
However doing so would IMO require creating one or several new repositories which the theories/ files would be moved to.
There, branches could be used to track different versions of the library, which we should make sure all compile with the supported versions of Coq (or at least several recent versions do).
With the Travis infrastructure, we can foresee that it would be relatively easy to make sure that the various supported versions of the library do indeed compile with the various supported versions of Coq.
But there might be technical difficulties taking that path. I think that @ejgallego has been doing work to be able to make Coq more independent of the stdlib but I don't how far this went. Ideally, we would like to retain in the main codebase only those files which are absolutely necessary for Coq to work OK.
I think that @mattam82 has also been considering this solution but postponed it for technical reasons.

I think that @ejgallego has been doing work to be able to make Coq more independent of the stdlib but I don't how far this went

This is in PR #186 , and indeed it is not too far from being in a mergeable state. Main objections to the PR were about the binding and namespacing mechanism, I favor a very simple solution there.

IMO require creating one or several new repositories which the theories/ files would be moved to.

We could also use a layout theories/v1.1/ etc... but indeed the other solution would be cleaner.

which we should make sure all compile with the supported versions of Coq

Indeed I'd say that even if the stdlib is moved to an independent repository, we should still have all of them as submodules in the main repository so make in Coq builds all the supported versions in development use.

Indeed I'd say that even if the stdlib is moved to an independent repository, we should still have all of them as submodules in the main repository so make in Coq builds all the supported versions in development use.

On the use of sub-modules for that particular application, I have to disagree: sub-modules require to specify a specific commit when including a dependency. This is very fine for many purposes, and I do personally use sub-modules for applications where this feature is actually handy. But I don't think that it makes sense here because each time the library would be updated, the main repo would need updating as well.
I would much more favor a model closer to what we have for Travis targets right now. When doing make ci-unimath it clones UniMath if it wasn't already done, pulls the latest changes otherwise and start the build. This could still be improved but this basically is what we would need for the stdlib as well. E.g. make ci-theories.

Indeed I see the problem, but however it seemed to me that using the "fresh build" model could be too unstable for the main Coq core codebase.

I was thinking that the libraries should be pinned at the Coq level, so you actually test what users will get. In this model is the library developers who need to be sure that their dev branch is OK with Coq.

In this model is the library developers who need to be sure that their dev branch is OK with Coq.

That seems to contradict the model you were advocating for, when testing external developments.

That seems to contradict the model you were advocating for, when testing external developments.

Umm, indeed external developers now seem to have the same contract "you need to be sure that your dev branch is OK with Coq", haven't they?

With the submodules, I was thinking more of how the regular Coq make should behave for developers. It seemed to a bit heavy to me to do a full checkout at every make, but maybe that is the right thing to do.

Honestly, I don't have a clear idea on what would be best. I most that I have thought is about splitting CoqIDE. The model I envisioned for CoqIDE was indeed the one where CoqIDE was independent, but always built by means of a submodule. The workflow would be as follows:

• Do changes to Coq, make.
• If CoqIDE doesn't break, fine! Commit.
• If CoqIDE does break, you fix it, then push both the fix the CoqIDE repos and the corresponding Coq commit bumps the submodule.

A page of wishes is fine to me. Actually, there are already some on cocorico. We could just add links to WIPs on such a page.

If discussion is warranted, maybe a CEP is the right place to have it?

For the sake of completeness, here is the CEP about versioning the library: rocq-prover/rfcs#18
I'm not really sure that we need to focus as much on smart ideas to improve compatibility, as soon as the library itself is versioned independently from Coq. At least, this is also the position defended by Michael Soegtrop.

Changing the flag from needs: progress to needs: discussion as this is change needs to be discussed as part of the more general question of the evolution of the standard library.

As was discussed at a WG, I find the direction taken by this PR worth to be investigated but it is not my priority considering the efforts in term of compatibility management that it requires.

As was more or less discussed at this WG according to my memories, I consider @maximedenes as taking over this PR. Shall @maximedenes would prefer to close it, I would just require that a trace of the idea remain somewhere.

@maximedenes Can you open a new issue or GitHub project or a wiki page or some place to collect all the ideas / projects related to the new Standard Library? Then, we can close this PR.

cc: #7312

Shouldn't we close this PR in the meantime?

Adding to the Stdlib 2.0 project and closing.

Note the trick: if you add it before closing, GitHub will move it in the "Done" column, which is not what we want.
If instead, you close it then you add it, GitHub will put it in the "Design questions" category, like it would for an open issue.