Next priority for OCaml?

[gasche]

I would be hard pressed to mention one priority for OCaml, because I think that many things are important – and important in different ways for different people. I thought that I could give some information on what support I have been involved in, either as a compiler maintainer or as a member of the OCaml Software Foundation, on some of the topics that have been mentioned here.

• Modular implicits: we’ve been trying to find people we could fund to make progress on this, but it is difficult – it requires a lot of type-system expertise, and time. We are funding internships with @yallop in Cambridge to experiment with the system, and I am thinking of getting my hands dirty during the next school year with some module-side implementation work – possibly diving into the PRs of Matthew Ryan.

• Type system for effects: I have decided to setup an informal working group for people interested in working on this (mostly academics, also Jane Street) to exchange information, and in particular to decide a common set of evaluation criteria – with compatibility with existing non-effect-using OCaml code as a top priority. I hope to announce something more structured next September, with the aim of getting a clearer idea of potential design proposals by the end of the academic years.

• Debuggers: the OCaml Foundation funded ocamlearlybird’s author in 2020-2021, hackwaly, before they stopped to work full-time for a startup. ( [ANN] ocamlearlybird now an OCaml Software Foundation supported project , [ANN] ocamlearlybird 1.0.0 beta1 , etc. ) I learned a week ago that @sim642 is interested in continuing maintenance of the project, and we are looking at funding his work.

  (ocamlearlybird is a bytecode debugger, similar to the venerable ocamldebug – it is a client for the same debugger protocol. Separately we would ideally have good debugging support with the native compiler. That aspect of the debugging story has been worked on by Mark Shinwell in the past, but there is a disagreement among compiler maintainers about what is the right technical approach to support DWARF information in the compiler – it is a complex format that is not necessarily a good match for OCaml, and adding it to the compiler backend is fairly invasive.)

• A priority that people don’t know about, but in my mind comes before “typed effects”, is to refactor and cleanup the implementation of the OCaml type checker, which has historically been a place of technical debt in the compiler. There has been a fair amount of work on this in the last year, driven by Jacques Garrigue as his group at Nagoya ( in particular Takafumi Saikawa ), with Florian Angeletti and myself on the reviewer side, and in the last few months some very welcome help from the Jane Street group working on language features (in particular Richard Eisenberg, Chris Casinghino, Nick Roberts) who have been lending a hand on refactoring and refactoring-reviewing work.

  More generally, I have been worried this year about maintenance workforce for the OCaml compiler codebase ( Maintenance bottlenecks in the compiler distribution ). I think that solving this issue is also a priority, at the level of the compiler distribution. We have made some progress, with notably maintenance contributions from OCamlPro and Jane Street, but I think that the situation still requires careful monitoring.

• Relocatability: I agree with @smorimoto that this is important. I would want all OCaml packages to be relocatable, notably as the right first step to enable caching or even binary distribution of OCaml package build artifacts. There has been work in this direction from David Allsopp in the last few years, which I understand gets closer every year to being in a state that could be submitted as upstream PRs. My strategy so far is to wait for this to make progress.

• Tooling, things that directly come to mind are:

  • development-environment tools whose recommended workflow is to have separate/isolated development environment(s) for each project. The opam client allows this with local switches, but I think the UI could be streamlined a bit to make this the easy default. (For example, not everyone knows how to build a local switch with only the dependencies of the project installed, to start hacking on it.) Ideally we would have caching of package builds across those development environments, and maybe even some distributed caching of build artifacts (assuming relocatability).
  • a “code upgrade” tool to which I can specify program transformations (for example: “rewrite SomeLib.somefun $bar $baz into SomeLib.somefun $bar (Somelib.convert $baz)”, and it applies it to my source code in a diff-friendly way.