Patrick Ferris 2026 3 30 https://patrick.sirref.org/ppxlib-release-0-38-0/ ppxlib-release-0-38-0 /ppxlib-release-0-38-0/ Ppxlib Releases › 0.38.0 Nathan and I released ppxlib.0.38.0 last week. Its main feature is full migration support for the upcoming OCaml 5.5 compiler (currently in its alpha3 release). This means supporting the handful of new features landing in OCaml 5.5: modular explicits, external type declarations and arbitrary "local" structure items. As Nathan and I continue to find a plausible maintenance story for ppxlib, Nathan has opened an issue on the OCaml compiler to discuss the idea of adding additional extension points to the language. This comes from the desire to be able to store encoded versions of new OCaml features inside older abstract syntax trees. There are also some nice bug fixes in there too: A potential OOM loop has now been removed. Locations have been restored to long identifiers! References Context Patrick Ferris 2026 4 3 https://patrick.sirref.org/weekly-2026-w14/ weekly-2026-w14 /weekly-2026-w14/ Forking in Shells & Library Maintenance This week, Merry got close to executing apt-get install ca-certificates and running Debian's debootstrap scripts correctly. Nathan and I released Ppxlib 0.38.0, I added support to ocaml-proj for compiling to the browser and I fixed a long-standing bug in hilite. Patrick Ferris 2026 4 3 Forking in Merry So far, Merry has managed to support many features of the POSIX shell specification without needing to do a fork(2) without an exec. Or, to put it another way, all the forking that Merry does, will only be followed by running C code. This is actually a feature of Eio's Process API. It is required to make process execution safe in the context of multiple domains in OCaml (mostly due to ensuring consistency within the garbage collector). However, it is perfectly okay to fork and run OCaml code provided there is only a single domain. In a shell, many features of the shell language require that commands (or built-ins, function applications etc.) execute within a subshell. The specification does not go into detail about how shells should implement this, but many choose to fork in order to preserve some state in the parent (for example, the file descriptor table). Some shells try to minimise the number of forks as an optimisation. The korn shell (ksh) is one such shell. Using the notation $(command) will cause command to execute in a subshell of the current ksh. In many instances, ksh will not actually fork/exec a subshell when command is a built-in or a shell function. By trying to adhere to Multicore OCaml's "thou shalt not fork" commandment, Merry is much more similar to ksh in this regard. However, whenever there is an interaction with a shell built-in and semantics that need a child process, things get tricky very quickly. Consider the following: while echo " hello " ; do : done | head -n 3 We have a mix of shell built-ins, normal commands, a compound command (the while loop) and a pipeline. Each individual command in the pipeline requires you to run them in a subshell and set them up before executing them. Without a fork for that first command, you may end up looping forever which is not the intended behaviour here. I had a good conversation with Michael about the implications of this for reproducibility. For now, I have started implementing a fork for some of the shell features whilst still trying to maintain the functional core of the implementation. Patrick Ferris 2026 4 3 An OCaml 5.5 compatible Ppxlib Nathan and I released an OCaml 5.5 compatible version of ppxlib. Patrick Ferris 2026 3 30 https://patrick.sirref.org/ppxlib-release-0-38-0/ ppxlib-release-0-38-0 /ppxlib-release-0-38-0/ Ppxlib Releases › 0.38.0 Nathan and I released ppxlib.0.38.0 last week. Its main feature is full migration support for the upcoming OCaml 5.5 compiler (currently in its alpha3 release). This means supporting the handful of new features landing in OCaml 5.5: modular explicits, external type declarations and arbitrary "local" structure items. As Nathan and I continue to find a plausible maintenance story for ppxlib, Nathan has opened an issue on the OCaml compiler to discuss the idea of adding additional extension points to the language. This comes from the desire to be able to store encoded versions of new OCaml features inside older abstract syntax trees. There are also some nice bug fixes in there too: A potential OOM loop has now been removed. Locations have been restored to long identifiers! Patrick Ferris 2026 4 3 Browser support for ocaml-proj A while ago I built some "modern" bindings to PROJ4 in OCaml. After reading Jon Ludlam's weeknotes (and speaking with him and Anil, I thought it might be nice to add a Javascript backend to those bindings). This was relatively straight-forward using Dune's virtual libraries and is available on Github. With virtual libraries, your own data analysis could (if you wished) depend solely on the proj library and later choose to either link it with proj.c or proj.js depending on where the analysis is being deployed. I briefly looked at WASM support, but quickly realised there was not much appetite for it and trying to compile around the C FFI was going to be hard. Patrick Ferris 2026 4 3 Hilite updates Since I helped relaunch the ocaml.org website a few years ago, I have maintained hilite, a tool for doing build-time syntax highligting. It is being used on the ocaml.org website, in yocaml_markdown and also in Michael's webplats (when it works...). And it was Michael who led me to finally fixing and adding syntax highlighting support for Python and Go. Once I was on this roll, I finally took a look at fixing the long-standing bug of trying to highlight ocaml-mdx code, like the following: # 50.123 ; ; # 1 " file.ml " ; ; In fact, this code now highlights fine, but was the source of the bug. The syntax highlighting grammer confuses the ocaml-mdx # as a toplevel directive and trouble ensues. Patrick Ferris 2026 3 30 https://patrick.sirref.org/weekly-2026-w13/ weekly-2026-w13 /weekly-2026-w13/ Ppxlib release and Merry updates Patrick Ferris 2026 3 30 https://patrick.sirref.org/ppxlib-release-0-38-0/ ppxlib-release-0-38-0 /ppxlib-release-0-38-0/ Ppxlib Releases › 0.38.0 Nathan and I released ppxlib.0.38.0 last week. Its main feature is full migration support for the upcoming OCaml 5.5 compiler (currently in its alpha3 release). This means supporting the handful of new features landing in OCaml 5.5: modular explicits, external type declarations and arbitrary "local" structure items. As Nathan and I continue to find a plausible maintenance story for ppxlib, Nathan has opened an issue on the OCaml compiler to discuss the idea of adding additional extension points to the language. This comes from the desire to be able to store encoded versions of new OCaml features inside older abstract syntax trees. There are also some nice bug fixes in there too: A potential OOM loop has now been removed. Locations have been restored to long identifiers! Patrick Ferris 2026 3 30 Merry updates It turns out writing a POSIX(ish) shell is hard; at least, there is a vast number of slightly obscure features that one needs to support. I think this is surprising because most people writing shell scripts write simple shell scripts; scripts that use a much smaller subset of features. In the same breath, those same developers are likely to use something like apt-get install bash which runs a plethora of more advanced (and non-POSIX) shell scripts! Patrick Ferris 2026 3 30 Exec redirects In a shell script, you can use the built-in command exec to replace the current process with a new one (e.g. exec vim). However, there is a different mode of operation for exec: If exec is specified with no operands, any redirections associated with the exec command shall be made in the current shell execution environment. One of my litmus tests for Merry is the Debian debootstrap scripts (h/t Anil). One thing that it does is the following: err printf " err $ 1 " >&4 exec 4>&1 A lot of detail has been elided for clarity. exec 4>&1 sets up a redirection for the shell's execution environment in which file descriptor 4 is now an alias for standard output. So, writing to 4 (by redirecting a command's standard output to 4 i.e. >&4) will output to where standard output is going (most likely the terminal). For this to work, shell's must dup2 the relevant file descriptors which have the following condition: If the file descriptor newfd was previously open, it is closed before being reused; the close is performed silently (i.e., any errors during the close are not reported by dup2()). This is all very well, unless your program has an important file already open that happens to have file descriptor 4. The Eio Linux and POSIX backends suffer from this problem. Both make use of a file-based synchronisation mechanism for waking up the eventloop should another domain push a completion to the scheduler's run queue. On Linux this is via an eventfd and in POSIX, a pipe. This dup2 will close the eventfd and will likely grind Eio to a halt (or an assert false). For now, I have resorted to vendoring Eio and moving the eventfd file descriptors to higher values, though I have opened a PR to make this more configurable. This bug is quite easy to write up... it was not so easy to find! As a random example, consider the debconf/confmodule script which offers very little room for a buggy implementation! Patrick Ferris 2026 3 30 Outreachy The presentations from the demonstrations for this round of Outreachy are now online! Patrick Ferris 2026 2 9 https://patrick.sirref.org/outreachy-ocaml-tiff/ outreachy-ocaml-tiff /outreachy-ocaml-tiff/ Write support in OCaml TIFF library I am mentoring Tambe Salome during the December 2025 Outreachy round to add support for writing TIFF files in the ocaml-tiff library. You can now see the video of the demonstration day presentation: Patrick Ferris https://patrick.sirref.org/ppxlib-releases/ ppxlib-releases /ppxlib-releases/ Ppxlib Releases Patrick Ferris 2026 3 30 https://patrick.sirref.org/ppxlib-release-0-38-0/ ppxlib-release-0-38-0 /ppxlib-release-0-38-0/ 0.38.0 Nathan and I released ppxlib.0.38.0 last week. Its main feature is full migration support for the upcoming OCaml 5.5 compiler (currently in its alpha3 release). This means supporting the handful of new features landing in OCaml 5.5: modular explicits, external type declarations and arbitrary "local" structure items. As Nathan and I continue to find a plausible maintenance story for ppxlib, Nathan has opened an issue on the OCaml compiler to discuss the idea of adding additional extension points to the language. This comes from the desire to be able to store encoded versions of new OCaml features inside older abstract syntax trees. There are also some nice bug fixes in there too: A potential OOM loop has now been removed. Locations have been restored to long identifiers! Backlinks Related Patrick Ferris https://patrick.sirref.org/modular-explicits/ modular-explicits /modular-explicits/ Modular Explicits in OCaml Abstraction, in OCaml, often refers to hiding a particular type's implementation using a signature. For example: module S : sig type t val add : t -> t -> t end = struct type t = int let add = Int . add end In this post, however, I use abstraction to refer to the notion of code-reuse. Using features of the OCaml language to allow one piece of code to be used across different implementations or instantiations of a particular kind of value. The goal of this post is to eventually discuss OCaml 5.5's modular explicits which is yet another feature that can allow a single piece of code to be used in various situations. Patrick Ferris https://patrick.sirref.org/abs-polymorphism/ abs-polymorphism /abs-polymorphism/ Polymorphism The most prevalent kind of abstraction is polymorphism. For example, List.length will work for all lists regardless of what kind of elements the list contains. However, polymorphism requires you to keep the polymorphic part of the type at arm's length. This can lead to suboptimal performance and/or limited usefulness. List.mem is a good example; in order to be polymorphic List.mem relies on Stdlib.(=), the polymorphic equality operator. In turn, this operator achieves its polymorphism by performing a structural comparison of the runtime representation of its arguments. A common way to overcome this is to use higher-order functions (functions that take functions as arguments). # let rec mem ? eq = Stdlib . = v = function | -> false | x : : xs -> eq v x || mem ~ eq v xs val mem : ? eq : 'a -> 'a -> bool -> 'a -> 'a list -> bool = < fun > # let mem_int_list = mem ~ eq : Int . equal val mem_int_list : int -> int list -> bool = < fun > This works well in plenty of cases (List.map, Hashtbl.iter, etc.), however, it doesn't scale well from a user's perspective if the body of the function requires lots of specific functions (e.g. compare, length, pp). At the same time, we want to avoid the precarious duck-typing of something like Python too. Patrick Ferris https://patrick.sirref.org/abs-functors/ abs-functors /abs-functors/ Functors Functors are perhaps the second most prevalent feature of OCaml when it comes to code reuse. In the OCaml sense, a functor is a module that is parameterised by other modules. Set.Make is a functor that requires a module adhereing to the Set.OrderedType interface. module IntSet = Set . Make Int module StringSet = Set . Make String Functors make it a lot easier to write implementations that depend on a large variety of functionality. Set.OrderedType is relatively tame in this sense, only needing a type t and a compare : t -> t -> int function. Irmin, on the other hand, has functors that require users to provide Schemas. I have more thoughts about this API design in my Irmin retrospective. It is important to consider the runtime costs of functors too. Whilst most of the time functors are instantiated at the toplevel, it does not come for free. You can have a play around with js_of_ocamlopt and see the generated output for how functors are applied. Patrick Ferris https://patrick.sirref.org/abs-fcm-exist/ abs-fcm-exist /abs-fcm-exist/ First-class Modules and Existentials Sitting somewhere inbetween polymorphism and functors are first-class modules with existentials. This is a rather advanced use of OCaml's type system to be able to pack together a value of a particular type alongside a module that works with those kinds of values. type set = Set : module Set . S with type t = 'a * 'a -> set let size Set module S , s = S . cardinal s Packaging up integer sets is fairly straight-forward. # let int_empty_set = Set module IntSet , IntSet . empty val int_empty_set : set = Set < module > , < poly > From a user's perspective we are now closer to the realm of dynamic typing. Indeed, existentials are the way to do that in OCaml. # type any = Any : 'a -> any type any = Any : 'a -> any # let any v = Any v val any : 'a -> any = < fun > Getting back into a typed world often involves some type witness gymnastics or runtime exceptions. Used sparingly, however, it can be very effective particularly when a user is none the wiser about the use of FCMs and existentials. I have made use of this trick to package together Irmin stores with implementations. You could not, however, simply return the value that was packed away inside the existential. # let woops Set _ , s = s Line 1 , characters 26 - 27 : Error : The value s has type $ a but an expression was expected of type 'a The type constructor $ a would escape its scope Hint : $ a is an existential type bound by the constructor Set . There is also a runtime cost to the packing (and unpacking) of the module, not to mention the need for the extra allocation to create the existential in the first place. This will likely not be too significant, but is worth considering. Patrick Ferris https://patrick.sirref.org/abs-modular-explicits/ abs-modular-explicits /abs-modular-explicits/ Modular Explicits OCaml 5.5 has module-dependent function types also known as explicits modular. The type of a function can now depend on types that come from a module that is also part of the function definition. # let set_length : module S : Set . S -> S . t -> int = fun module S v -> S . cardinal v ; ; val set_length : module S : Set . S -> S . t -> int = < fun > # set_length module IntSet IntSet . empty ; ; - : int = 0 # set_length module StringSet StringSet . empty ; ; - : int = 0 In fact, we can now return values of a particular type that depends on a particular module! # let empty_set : module S : Set . S -> S . t = fun module S -> S . empty ; ; val empty_set : module S : Set . S -> S . t = < fun > # empty_set module IntSet ; ; - : IntSet . t = < abstr > # empty_set module StringSet ; ; - : StringSet . t = < abstr > Or, we can dynamically select implementations and values. # let with_impl : config : string -> module S : Set . S -> S . t -> 'a -> 'a = fun ~ config fn -> match String . lowercase_ascii config with | " string " -> fn module StringSet StringSet . empty | " int " -> fn module IntSet IntSet . empty | c -> invalid_arg c val with_impl : config : string -> module S : Set . S -> S . t -> 'a -> 'a = < fun > This is like a more usable version of the FCM-existential trick, though does require more manual type annotations on functions. For instance, I tried switching out OBuilder's use of existentials with modular explicits: builder - let log tag msg = match tag with | `Heading -> Fmt.pr "%a@." Fmt.(styled (`Fg (`Hi `Blue)) string) msg | `Note -> Fmt.pr "%a@." Fmt.(styled (`Fg `Yellow) string) msg | `Output -> output_string stdout msg; flush stdout -let create_builder store_spec conf = +let create_builder : + Store_spec.store Lwt.t -> Native_sandbox.config -> + ((module B : Obuilder.BUILDER) -> B.t -> 'a) -> 'a Lwt.t = + fun store_spec conf fn -> store_spec >>= fun (Store_spec.Store ((module Store), store)) -> let module Builder = Obuilder.Builder (Store) (Native_sandbox) (Docker_extract) in Native_sandbox.create ~state_dir:(Store.state_dir store / "sandbox") conf >|= fun sandbox -> let builder = Builder.v ~store ~sandbox in - Builder ((module Builder), builder) + fn (module Builder) builder]]> I think the code is more pragmatic; there is no longer an indirection via a type called builder. The extra type annotations do add a little noise. Roll on modular implicits. https://patrick.sirref.org/nathanreb/ nathanreb /nathanreb/ Nathan Rebours person https://github.com/nathanreb Maintainer of Ppxlib. https://patrick.sirref.org/ppxlib/ ppxlib /ppxlib/ Ppxlib https://github.com/ocaml-ppx/ppxlib An OCaml library and ecosystem for preprocessing. Contributions