I vaguely remember seeing some sort of comments to the effect that a renovation of the base OCaml documentation was being contemplated, but after searching I’ve not been able to find any mention of it, so I may have been mistaken. Am I imagining having heard about this?
(The upcoming migration of the Coq documentation to Sphinx reminded me to ask about this.)
I am not sure which “documentation pages” you are talking about.
There is the official OCaml Manual, the reference documentation, which I personally think is surprisingly good. I am not aware of a big revamp plan, although @octachron would be the person to ask about changes to the manual (he has been contributing a lot of nice things to it in the last few years). On the other hand, it has been mentioned a couple time that the web output is currently ugly, so I guess that some people may be willing to work on improving this – this doesn’t need to be an invasive change.
There are some user-contributed tutorials on ocaml.org that are very unequal in quality and would need people willing to work on them (either migrate the information away into better places, or revamp them; personally I think the first option would be better)
The documentation-generation tool for .mli files, ocamldoc, has acknowledged limitations, and there exists a plan to implement a better one that has been running since 2013 (opam-doc, now odoc). The progress on this is irregular, my understanding is that odoc is already usable today – for example some version of it powers docs.mirage.io – but as far as I know it hasn’t been officially released and there is little information online about how someone not involved in its development may want to use it. (While ocamldoc is understood to have fundamental limitations, it is reasonably well maintained and evolves in tandem with new OCaml features.)
My purely personal guess is that the OCaml manual will stay mostly the same, but get a more modern web design, that the ocaml.org tutorials will be removed (how much of the work poured into them will be lost depends on whether people are willing to volunteer work), and that odoc will eventually (in some unpredictable amount of time) become the standard documentation generator – with public documentation generated at a centralized opam-repository level instead of documentation pages being hosted locally (or not hosted at all) by each package author.
I’m curious what the plans are. This is the sort of thing where newcomers like me can be of help — converting documents from one form to another often requires only limited experience.
Since the html version of the manual is mostly generated from latex source files and ocaml interface files; there is not real need for migrating or converting the documents themselves. Currently, in term of manual infrastructure, my mostly non-ordered todo list looks like:
finish the verbatim mode for code examples
refresh the html structure generated by hevea/hacha for individual html pages
add a option in the manual build system to generate the API documentation with odoc rather than ocamldoc
write a latex backend to odoc
update the graphical chart of the manual (by updating the corresponding css styles)
discuss with @avsm about potentially hosting the manual on ocaml.org and reusing its graphical chart
I am not sure if any of this task is newcomers friendly, even more so when compared to writing documentation: for instance, on error or warning messages; or about using lazy values, ephemerons or the Format module.
Hello, you can see currently filed issues on the bug tracker to get an idea of what people want to see improved: https://caml.inria.fr/mantis/view_all_bug_page.php (set the ‘Category’ to ‘ocamldoc’ and then click ‘Apply Filter’).
The formatting in both of those is very clean and easy to read. The typesetting shows indicates very naturally to the reader what is important and what isn’t, where you should start and end reading any given topic, etc. I realize many people don’t recognize the importance of good typography in making it easier to read documentation, but it has major effects on usability.
Similarly, Paul Steckler and others are working on a conversion of the Coq documentation to Sphinx (which is the system used for Python’s documentation). Here is what it looked like before, which I find rather unreadable. Here’s what it looks like converted, which I think is vastly nicer.
Well this is rather easy, and interested people should not hesitate to contribute.
I started working on this in the following Pull Request #1209. There are things to improve in the manual rendering before we can merge this (and the improvement may require more hacking, so beginners are welcome but this may or may not turn out to be easy), but continuing the work of porting code example in the manual to the new caml_example environment is rather simple.
There is information in manual/README.md on how to build the manual and how to use the caml_example environment. Any further question can help improve this documentation.