OCaml Toolbox [octx]

August 18, 2026
Patrick Ferris
https://tangled.org/patrick.sirref.org/octx

OCaml Toolbox (octx) is a CLI tool for generating OCaml code. It uses various ppxes, and built-in functionality to produce OCaml code. The output from octx is meant to be edited and modified to suit the user's needs.

As an example, imagine you have a type t:

type t = {
  name : string;
  age : int
}

And you want to make a Jsont representation of it. You could write this by hand. You could add a dependency on ppx_deriving_jsont. Or, you could use octx in your editor, and select your type and pass it to octx run -d jsont - | ocamlformat --enable-outside-detected-project --impl -.

let jsont =
  let make name age = { name; age } in
  Jsont.Object.map ~kind:"T" make
  |> Jsont.Object.mem "name" Jsont.string ~enc:(fun t -> t.name)
  |> Jsont.Object.mem "age" Jsont.int ~enc:(fun t -> t.age)
  |> Jsont.Object.finish

Of course, the ocamlformat-ing is completely optional, but tends to produce a slightly more human-readable version of the ppx-generated code.

At the time of writing, octx supports the following derivers:

"ppx_deriving_yojson"
"ppx_deriving_yaml"
"ppx_sexp_conv"
"ppx_deriving_jsont"
"ppx_deriving"
"ppx_fields_conv"
"ppx_hash"
"ppx_string_conv"

Backlinks

Boilerplate [on-boilerplate]

August 11, 2026
Patrick Ferris

The word boilerplate gained popularity as a colloquialism used by newspaper and magazine editors for pre-prepared editorials and stories that were syndicated across the US. In effect, boilerplates were news stamps that could produce identical content.

I have been thinking about the nature of boilerplate code. How is it similar or different to boilerplate in its original meaning.

Distinguishing true boilerplate code from code that feels repetitive or boring to write is, I think, important. Argument parsing falls into this category quite well. Consider the following flag I added to Merry's set built-in.

let all_export =
  let doc = "Export all variables, like -o allexport." in
  Arg.(value & flag & info [ "a" ] ~docv:"ALLEXPORT" ~doc)

It uses cmdliner to define a new -a flag that will, in effect, make all variable definitions act like the export built-in. LLMs have been praised for their ability to do this specific task in OCaml.

What exactly is boilerplate about this code snippet? It seems to me that there is some sort of ceremony to defining a flag. There is boilerplate in the structure with more meaningful content threaded through. Below, is the example reduced to just the boilerplate replacing the for more meaningful parts with Merlin's typed holes: _.

let all_export =
  let doc = _ in
  Arg.(value & flag & info [ _ ] ~docv:_ ~doc)

Arguably the use of flag is quite important too as that is where the magic happens if you want an optional argument, or a positional one etc. As a thought experiment, having agents deliver fill-in-the-blanks style code might be quite useful. In a type system that can support holes (e.g. like in OCaml or Hazel) it becomes a more pleasant exercise, but helps keep you in the loop. I, myself, do not use any AI in the code I write; so I admit that I am pretty far from the problem.

The problem I have with this approach is that it is fairly easy to automate in a predictable and easy way! I just added a snippet subcommand to octx, but you could easily wrap this up in whatever your editor of choice is.

$ octx snippet cmdliner-flag
let cmdliner_flag =
  let doc = _ in
  Arg.(value & flag & info [ _ ] ~docv:_ ~doc)

The more I think on this problem the harder I find good uses for LLMs besides churning out vasts amount of end-to-end code; something I am personally not that interested in doing. It seems to me, to reap the benefits of LLMs, one must relinquish a certain amount of agency; anything less, and you could easily replace its usage with a cheaper, more predictable tool.