The future of OCaml PPX: towards a unified and more robust ecosystem

OCaml 4.02 introduced the PPX language feature to replace Camlp4 with a more uniform way of defining language extensions that would share a syntax understood by all. PPX rewriters have since then been used as code generator in a variety of ways such as deriving boilerplate functions from type definitions using [@@deriving ...] attributes in a Haskell-like fashion or making monadic style syntax more readable. A whole range of tools and drivers emerged to help PPX rewriters authors: ppx_tools, ppx_deriving, ocaml-migrate-parsetree, ppx_tools_versioned and later ppxlib.

The maintainers of these projects have worked to make them cohabitate but it has been a struggle and, as the existing PPX rewriters are still spread accross the whole ecosystem, it is sometimes impossible.

The ppxlib (soon to be renamed ppx) team has started an effort to unify the whole ecosystem. In this talk we’ll explain what the plan is and how we intend to solve the known issues with the current ways of writing PPX rewriters. In particular we’ll cover how we plan to relieve PPX rewriters authors from the weight of migrating their code to the newest AST while still making it easy to support new langage features. To achieve that we will expose an AST that can represent any version of the OCaml langage (from a certain point on) through an API that introduce no breaking changes between minor OCaml releases as opposed to the current Parsetree module from compilerlibs.

Such an API would protect PPX authors from the need to rewrite transformations that work on a given OCaml release after a new version of the langage is released, even if this new version introduces changes to the involved parts of the AST. As an example, in order to support exception declarations with attributes introduced in OCaml 4.08, a PPX author wouldn’t have to change the code handling exception declarations without attributes as they would always be parsed to the same AST, even when using an OCaml version higher than 4.08.