-
Notifications
You must be signed in to change notification settings - Fork 34
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
base: master
Are you sure you want to change the base?
Changes from 8 commits
9b75f25
564fa10
07b78d0
03caa41
a3d8194
35f6767
0d72bfc
12029f9
cb6f23f
1e56e11
440b7cd
ca1ccbf
cb57a6d
641d53a
24406ff
161d40b
973a85d
9bdbd39
8b9c8fd
22b6e7b
1ec6a9c
d453219
1ca6088
5ac7604
20ec62f
cf29405
66f4a7a
a51d5f4
fa6d9a7
770a30b
ec59e93
15122d1
9f3238d
993481d
cbbc0ce
eb86523
fa1f1d5
43a1744
6b98014
f8ebc9f
99efed4
8e06250
e622f78
8f5fef3
84ddd43
f46000b
20a90fc
5487a1b
a4a81c1
43f96b1
609c3b4
fcf08d0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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, | ||
- what resources are available to work on these axes, and which axes we commit | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "we" means the Core Team only? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
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". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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).
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.
Yes. Better wording welcome!
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.
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). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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." There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, although I would probably use a word that has a similar meaning to "encourage", but stronger. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "we urge" seems appropriate in this case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ideally, it would be versioned. Might be interesting to diff between versions. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's improve the process step by step.
Yes, sure. I would be interested in reading what you have in mind here.