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

Short-term roadmap for Coq #69

Draft
wants to merge 52 commits into
base: master
Choose a base branch
from
Draft
Changes from 8 commits
Commits
Show all changes
52 commits
Select commit Hold shift + click to select a range
9b75f25
First draft of Coq roadmap based on initial discussion at CUDW 2023.
Zimmi48 Jul 17, 2023
564fa10
Edits after meeting with Nicolas.
Zimmi48 Jul 17, 2023
07b78d0
add Yann Leray
tabareau Jul 17, 2023
03caa41
Add Nicolas to the CEP drivers.
Zimmi48 Jul 17, 2023
a3d8194
Draft rewrite rules for 069-coq-roadmap.md
TheoWinterhalter Jul 18, 2023
35f6767
069 coq roadmap: sell a bit more rewrite rules
TheoWinterhalter Jul 19, 2023
0d72bfc
Update text/069-coq-roadmap.md
Zimmi48 Jul 19, 2023
12029f9
Merge pull request #70 from TheoWinterhalter/patch-1
Zimmi48 Jul 19, 2023
cb6f23f
Splitting very long lines.
Zimmi48 Aug 1, 2023
1e56e11
Add description of the promote platform / demote stdlib items.
Zimmi48 Aug 4, 2023
440b7cd
Fix typo.
Zimmi48 Aug 7, 2023
ca1ccbf
Update 069-coq-roadmap.md (fixpoints and sections)
herbelin Sep 26, 2023
cb57a6d
Update 069-coq-roadmap.md
gares Sep 26, 2023
641d53a
Update text/069-coq-roadmap.md
gares Sep 26, 2023
24406ff
Update 069-coq-roadmap.md
mattam82 Sep 26, 2023
161d40b
Update 069-coq-roadmap.md for sort poly
SkySkimmer Sep 27, 2023
973a85d
Merge pull request #76 from coq/mattam82-patch-1
Zimmi48 Sep 29, 2023
9bdbd39
Merge pull request #75 from coq/gares-roadmap
Zimmi48 Sep 29, 2023
8b9c8fd
Update 069-coq-roadmap.md
gares Oct 3, 2023
22b6e7b
Add ressources to "move stdlib to coq-community"
proux01 Oct 4, 2023
1ec6a9c
small explanation of the ltac2 item
SkySkimmer Oct 4, 2023
d453219
Merge pull request #77 from coq/gares-patch-69
SkySkimmer Oct 4, 2023
1ca6088
Update 069-coq-roadmap.md
SkySkimmer Oct 4, 2023
5ac7604
Revert title of "Demote stdlib" section
proux01 Oct 5, 2023
20ec62f
Wording improvement.
Zimmi48 Oct 6, 2023
cf29405
Update 069-coq-roadmap.md
herbelin Oct 8, 2023
66f4a7a
Update 069-coq-roadmap.md
herbelin Oct 8, 2023
a51d5f4
Extend Ltac2 roadmap a bit.
ppedrot Oct 10, 2023
fa6d9a7
Update 069-coq-roadmap.md
yforster Oct 10, 2023
770a30b
Update 069-coq-roadmap.md with proper links to PRs
silene Oct 10, 2023
ec59e93
Update 069-coq-roadmap.md
gares Oct 10, 2023
15122d1
Update 069-coq-roadmap.md
SkySkimmer Oct 10, 2023
9f3238d
add renaming Coq -> Rocq
tabareau Oct 11, 2023
993481d
minor fixes
tabareau Oct 11, 2023
cbbc0ce
fix name
tabareau Oct 11, 2023
eb86523
Promise a CEP to plan stdlib changes
proux01 Oct 11, 2023
fa1f1d5
Update 069-coq-roadmap.md
yforster Oct 11, 2023
43a1744
Merge pull request #79 from yforster/patch-2
tabareau Oct 11, 2023
6b98014
Update 069-coq-roadmap.md: docstrings
herbelin Oct 22, 2023
f8ebc9f
Restructure roadmap into short, medium and long term.
Zimmi48 Oct 24, 2023
99efed4
fixup! Restructure roadmap
Zimmi48 Oct 24, 2023
8e06250
Fix typo.
Zimmi48 Oct 24, 2023
e622f78
Add a paragraph about parsing
proux01 Oct 26, 2023
8f5fef3
Wording improvements.
Zimmi48 Nov 7, 2023
84ddd43
Move things around and detail a bit more some aspects of the medium t…
Zimmi48 Nov 7, 2023
f46000b
Update 069-coq-roadmap.md
SkySkimmer Dec 18, 2023
20a90fc
Link to stdlib CEP
proux01 Feb 6, 2024
5487a1b
Move parsing-recovery-mechanism removal to longer term
proux01 Feb 6, 2024
a4a81c1
Add people and timing to parsing task
proux01 Feb 6, 2024
43f96b1
Update 069-coq-roadmap.md
SkySkimmer Feb 22, 2024
609c3b4
update roadmap: remove sort poly (done), add template poly section
SkySkimmer Sep 10, 2024
fcf08d0
Fix various typos.
Zimmi48 Sep 26, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
200 changes: 200 additions & 0 deletions text/069-coq-roadmap.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,200 @@
- Title: Coq roadmap

- Drivers: Nicolas Tabareau (@tabareau), Théo Zimmermann (@Zimmi48)

----

# Summary

This CEP aims to establish a roadmap for the Coq project.
It highlights both:

- what are considered as important axes to work on in the future,
Copy link
Member

@jfehrle jfehrle Oct 5, 2023

Choose a reason for hiding this comment

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

What I see so far is a list of things that people plan to work on. This is a useful planning tool. But there's really no discussion about the priorities, relative priorities or why something is considered a priority. We should discuss the best ways to make Coq more useful to users without limiting it to things that people plan to work on in the near future. For example, I think there are a lot of very useful improvements to make to GUIs such as vsCoq2 that require support from Coq. Documentation needs a lots of work.

Seems like this should be a separate document and a different kind of discussion (i.e. in terms of user needs/pain points).

Copy link
Member Author

Choose a reason for hiding this comment

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

We want to map the priorities in terms of need with the individual priorities in terms of volunteering effort. But the second section (better names welcome for the sections!) is precisely meant to also discuss priorities without committed volunteer effort (and then we can use this second section to ask Inria for engineering support).

Copy link
Member

Choose a reason for hiding this comment

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

We want to map the priorities in terms of need with the individual priorities in terms of volunteering effort.

Not entirely sure what you mean here. There should be a place where we begin by stating user needs/priorities, then relating line items to the themes identified there and identifying which ones benefit users most and why. The technical work should flow from user needs and priorities. We're leaving them unstated and perhaps undiscussed. But I think the team is not used to thinking this way.

Maybe we come back to this later. If you like, I could provide a paragraph or two to fit into the document.

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe we come back to this later.

Yes, let's improve the process step by step.

If you like, I could provide a paragraph or two to fit into the document.

Yes, sure. I would be interested in reading what you have in mind here.

- what resources are available to work on these axes, and which axes we commit
Copy link
Member

Choose a reason for hiding this comment

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

"we" means the Core Team only?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, the roadmap is not limited to what the core team is going to work on. However, there should always be sufficient agreement or support from relevant maintainers to ensure that a change, if implemented, will also be included.

to work on based on these resources.

Resources mean availability of persons to conduct the work. For technical axes,
requiring changes in the Coq system, it includes availability of persons to
review and merge the changes.

# Motivation

Producing a roadmap for the Coq project is important for several reasons:

- It helps the community to know what to expect from the Coq project in the
future, in particular what changes can reasonably be expected to become
part of next releases, and what changes are more likely to be delayed
because of lack of resources.

- It helps Coq developers to focus on important axes, and to be more
efficient, by making sure that their work will be supported by other
developers, including reviewers.

- It helps contributors to know what are the important axes where their
contribution is most likely to be welcome and where they can expect
the most support from the Coq developers.
Zimmi48 marked this conversation as resolved.
Show resolved Hide resolved

Copy link
Member

Choose a reason for hiding this comment

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

I expect most contributors are motivated by their own ideas for improvements to the Coq and its ecosystem rather than asking "what project in this list do I want to join?". This document is only a limited subset of the potential areas (axes?) for improvement.

what are the important axes where their contribution is most likely to be welcome

Implying that some contributions are unwelcome is a poor choice of words. I think the issue is more about getting reviewer time. We should be willing to consider thoughtfully updating the roadmap at any time. We should make a reasonable effort to review contributions that arrive unexpectedly--discussing their value rather than just pointing to the roadmap and saying "It's not in the roadmap. Sorry but your contribution is unwelcome".

Copy link
Member Author

Choose a reason for hiding this comment

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

I expect most contributors are motivated by their own ideas for improvements to the Coq and its ecosystem rather than asking "what project in this list do I want to join?". This document is only a limited subset of the potential areas (axes?) for improvement.

If contributors are motivated by their own ideas for improvements, that's fine (although they should check with the maintainers if their ideas are likely to be accepted, when these ideas require large implementation work). However, there are also lots of contributors who are eager to help on priority axes (where they also know that they will receive the most help / feedback).

This document is only a limited subset of the potential areas (axes?) for improvement.

We should strive to not limit the document in terms of general areas of improvement. However, we should limit the document to just a few priority items by area, because having too many priorities is just like having no priority.

Implying that some contributions are unwelcome is a poor choice of words. I think the issue is more about getting reviewer time.

Yes. Better wording welcome!

We should be willing to consider thoughtfully updating the roadmap at any time.

Yes. We discussed this at a recent Coq Call. We said that probably the roadmap would be copied to the wiki and updated there. We should make sure to add relevant pointers here when this is the case.

We should make a reasonable effort to review contributions that arrive unexpectedly--discussing their value rather than just pointing to the roadmap and saying "It's not in the roadmap. Sorry but your contribution is unwelcome".

Yes. We should review all contributions that we receive. However, we should also make every effort to clearly communicate to potential contributors that large implementation works should not be started before the overall goal and design having been discussed with the maintainer (in an issue or a CEP).

Copy link
Member

Choose a reason for hiding this comment

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

However, we should also make every effort to clearly communicate to potential contributors that large implementation works should not be started before the overall goal and design having been discussed with the maintainer (in an issue or a CEP).

Yeah, but I'd phrase this more like "We encourage potential contributors to discuss their large planned contributions before they begin implementation, such as through a Github issue or a CEP."

Copy link
Member Author

Choose a reason for hiding this comment

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

However, we should also make every effort to clearly communicate to potential contributors that large implementation works should not be started before the overall goal and design having been discussed with the maintainer (in an issue or a CEP).

Yeah, but I'd phrase this more like "We encourage potential contributors to discuss their large planned contributions before they begin implementation, such as through a Github issue or a CEP."

Yes, although I would probably use a word that has a similar meaning to "encourage", but stronger.

Copy link

Choose a reason for hiding this comment

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

"we urge" seems appropriate in this case.

Copy link
Member Author

Choose a reason for hiding this comment

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

"we urge" seems appropriate in this case.

Thanks, that's what I was looking for.

- It helps highlighting the axes where more resources are needed, and
where the Coq project should try to find more resources.

# Detailed design

This roadmap is a consolidated view created by the Coq developers, based on
their shared understanding of the priorities of the project and of the
resources available to work on these priorities. It is completed by a
discussion with the community, as part of the CEP process.

The fact that an item is part of the roadmap does not mean that its design
is already fixed, as design can be part of the work to be done. Therefore,
disagreement can still arise on such items, and may require to be resolved
through PR reviews, or through the CEP process. However, if an item is
part of the roadmap, it means that the Coq developers are committed to
work on it, and that they have resources available to do so, including the
reviews, so the work should not stall because of lack of resources or lack
of interest.

The description of each item of the roadmap will include the available
resources, the expected duration of the work, and the expected outcome,
including any blocking issues that will need to be resolved to complete
the work, and any still unresolved questions to be answered.

Rules :

- An item cannot be part of the roadmap if it is not supported by at least
two persons, including at least one Coq maintainer to review the changes.
- No one should be committed to work on more than two items at the same time.

Each Coq Call will start with a roundtable about progress on items of the
roadmap.
Comment on lines +111 to +112
Copy link
Member

Choose a reason for hiding this comment

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

I suggest having developers break down their multi-month projects into a list of shorter tasks, each of which can ideally be fully completed in a couple of weeks. Very hard otherwise to tell how much progress is being made. Items on the list can be checked off in the document as they're completed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. This is a good suggestion. We are slowly changing the culture here, so I'm unwilling to make this a hard requirement (this is already difficult enough to get people to write what they have in mind), but I would definitely want to strive toward that.


Gaëtan Gilbert will be the technical coordinator of the roadmap, overseeing
progress being made.

Théo Zimmermann will be the editorial coordinator of the roadmap, proposing
to add and remove items, to reflect the evolution of the project.

## Priorities and resources

### Kernel, theory

#### Sort polymorphism

- Gaëtan Gilbert, Nicolas Tabareau
- 3 to 6 months

#### Algebraic universes

- Matthieu Sozeau, Pierre-Marie Pédrot
- 1 year

#### Rewrite rules

The goal is to add (unsafe) user-defined rewrite rules. This features allows users to add computation rules to axioms which can be useful for prototyping. It also allows for different kinds of computation rules with respect to what Coq currently permits: non-linearity, overlapping left-hand sides (*eg* one can write an addition on natural numbers that reduces on both sides: `0 + n` and `n + 0` both reducing to `n`).

It would be deactivated by default and be optionally on by *eg* setting `Rewrite Rules On`. They should be supported by unification and the main reduction machines (not `vm_compute` and `native_compute` for now, Coq should give a warning when those are used with rewrite rules on). Rewrite rules would propagate to any module that requires the module that defines them.
Zimmi48 marked this conversation as resolved.
Show resolved Hide resolved

- Working Coq fork: https://github.com/Yann-Leray/coq (examples in https://github.com/Yann-Leray/coq/blob/rewrite-rules/test-suite/success/rewrule.v).
Zimmi48 marked this conversation as resolved.
Show resolved Hide resolved
- CEP: https://github.com/coq/ceps/pull/50
- Yann Leray, Théo Winterhalter
- 3 to 6 month

#### Primitive projections

Debate on the design to be had between Hugo Herbelin and Pierre-Marie Pédrot.

### Surface language

#### Ltac2
Zimmi48 marked this conversation as resolved.
Show resolved Hide resolved

- Gaëtan Gilbert, Pierre-Marie Pédrot

#### Arbitrary recursive notations

- Hugo Herbelin, Pierre Roux

### Tools

#### Proved extraction

- Yannick Forster, Matthieu Sozeau
- 6 months to 1 year

Would require work on:

- Prop included in Type
- Module dependency analysis
- Hugo Herbelin + Yannick Forster

## Other axes, without sufficient resources

### Kernel, theory

#### Observational type theory

#### Global fixpoints

#### Primitive projections

- Removal of compatibility layer

#### Sections

#### Modules

### Surface language

#### AST / interpretation

- Emilio?

#### Bi-dimensional notations

- Emilio Jésus Gallego Arias, ??? (missing buddy)

#### Nametab / libobject

- Emilio Jésus Gallego Arias, ??? (missing buddy)

#### Removing clenv

#### Unifall

#### Unification heuristics

(improving evarconv)

#### Support for async tactics

#### Reactive elaboration

#### Functionalisation

### Libraries and community

#### Promote the Coq Platform

- Théo Zimmermann, ???

Editorial work + documentation

#### Demote stdlib

- Separation of the prelude
- Make stdlib a normal library

#### Tooling for building libraries

Copy link
Member

@jfehrle jfehrle Oct 5, 2023

Choose a reason for hiding this comment

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

How about listing improvements to the Ltac* debugger? I have several significant enhancements already complete. Only a couple more features to complete plus some cleanup and doc. It may be ready to present to the group in a month or less.

Copy link
Member Author

Choose a reason for hiding this comment

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

Feel free to contribute additional items like this one to this list. If items have a single person committed to them, they should appear in the second part, until they get at least a committed reviewer.

Note however that improvements to the debugger (if they are CoqIDE-oriented) risk clashing with some other goals that are likely to get on the roadmap to eventually retire CoqIDE. Adding debugger support to one of the language servers would then become a much higher priority than improving the debugger, IMHO.

(Coq universe)

# Drawbacks

TODO

# Alternatives

TODO

# Unresolved questions

- How to update the roadmap? Should this CEP be updated, or should we create new CEPs every few months to produce a new roadmap? Should we
also maintain a wiki page with the roadmap, to cover the live progress?
Copy link
Member

Choose a reason for hiding this comment

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

Ideally, it would be versioned. Might be interesting to diff between versions.

Copy link
Member Author

Choose a reason for hiding this comment

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

As mentioned above, what we currently envision is to copy and update the roadmap to the wiki, which is versioned as a git repository.