Fabrice Le Fessant has just set up a new company, OCamlPro, whose goal is to provide commercial support for OCaml, and to make it a more effective platform for people who use OCaml as a production tool.
I think this is great news, and says good things about the future of the language. The core team at INRIA has always done a great job of maintaining the compiler, but I had gotten worried over the last few years that they had lost interest in making further improvements.
The last year or so has proven that wrong. The improvements in OCaml 3.12 have been pretty dramatic. The arrival of first-class packaged modules really changes the fabric of the language in a meaningful way. Notably, the core features were implemented outside of INRIA, in particular, by the folk at LexiFi. And the improvements are not over; there is a lot of cool stuff coming in 3.13 as well.
But there are other areas where there’s been less progress; in particular, improvements to the runtime and to the surrounding toolchain have been less dramatic.
That’s where I’m hoping that OCamlPro will step in. We’re currently working with OCamlPro to improve the inlining and unboxing done by the compiler, but there are lots of other areas where we’re hoping that OCamlPro can drive improvements. Here’s a summary of some of the ideas we’ve been batting around with Fabrice and company. To be clear, this is all pretty speculative.
- Improving support for multicore systems by making it possible to run multiple OCaml runtimes on different threads.
- Improving the OCaml toolchain so that there is better support for IDE-style features such as autocompletion and integrated documentation.
- Adding support for namespaces, which should improve on the current approach of using so-called packed modules for grouping libraries.
- Improving support for writing type-driven code generators like sexplib and bin-prot without the going through camlp4. This should improve both speed of compilation and, critically, the ease of writing such extensions.
And there’s more. It’s a lot to do, and it’s not going to happen all at once. But I’m hopeful that OCamlPro will become a real driver of OCaml development. And our goal in all of this is to drive these changes upstream. That’s going to slow things down, but I believe the discipline of getting the changes up to the standards required by the core team will be worthwhile. And by keeping the work flowing upstream, we will avoid the problems of creating a permanent fork to the compiler.