OCaml compiler design and development

[gasche]

@Luc_ML

3/ Beyond declaring issues on GitHub - ocaml/ocaml: The core OCaml system: compilers, runtime system, base libraries and fixing them as usual in OSS, is there a defined design process, especially with formal/semi-formal requirements, and is there a steering committee?

There is no steering committee, but the people making integration decisions are the maintainers of the compiler distribution (which evolves in a fairly similar way to “who has commit bits” in most open source project: from time to time we invite active contributors to join), with Xavier Leroy playing the role of a benevolent-grumpy dictator.

@avsm recently gave a good description of (some approximation of) a language design process:

@avsm

• Substantive changes in the underlying theory are often best communicated using research papers. These can be long or short, peer-reviewed or on arXiv, and in venues ranging from your homepage to ICFP or the OCaml Workshop. The essential goal here is to lay out a thesis and justify it either experimentally or theoretically.
• Once you have some consensus on the broader picture, changes that will substantially modify OCaml’s behaviour can be posted to the RFCs repository, where they will be discussed online, and subsequently scheduled to be brought up in a core developer meetings.
• The core developer meetings are held regularly (formerly in person, now online), and aim to come out with a decision about accepting, declining or requesting modifications to a proposed change or RFC.
• Once a change has been agreed, posting a pull request to the main OCaml repository will have it undergo a series of reviews, after which it will be merged once it has sufficient approval from the OCaml developers.

Not every change has to go through this full process, of course, but the intention is to signpost upcoming changes well ahead of time such that design issues can be worked out before substantial effort has been put into implementation.

(I say “approximation” because for now RFCs are experimental; they are mostly used as a tool for language maintainers themselves, and it’s not working very well. Personally I wouldn’t encourage people to rely on it before we get better at handling RFCs; and even then, we would have problem if we had more RFCs submitted than people doing the work of reviewing and giving feedback – which is the state of the implementation right now.)