OCaml Weekly News
Hello
Here is the latest OCaml Weekly News, for the week of March 03 to 10, 2026.
Table of Contents
Eliom 12: Client-server applications in Web Assembly
Vincent Balat announced
On behalf of the Ocsigen team, I am pleased to announce the release of Eliom 12. Following our recent release of wasm_of_ocaml, this version's main feature is full support for Web Assembly. Eliom applications are now served by default as Web Assembly programs (with a JavaScript fallback). The default build system has been adapted accordingly. The Ocsigen Start template has also been updated.
The new version are available in opam.
If you want to give it a try, please read the main documentation page first.
You can see a running example app here.
melange-str: Str module for Melange
David Sancho announced
melange-str is an implementation of OCaml's Str module for Melange, using JavaScript's RegExp as the backend.
OCaml's Str library provides regular expression matching, searching, replacement, and splitting. It's part of the standard distribution and widely used. However, Str is implemented in C, which means it's unavailable when compiling OCaml to JavaScript via Melange.
The module is exposed as Str (not Melange_str.Str), so existing code that opens or references Str works without changes.
Repository: https://github.com/davesnx/melange-str
Feedback, bug reports, and contributions are welcome. If you encounter any behavioral differences between native Str and melange-str, please open an issue or let me know!
Outreachy May 2026
Continuing this thread, Patrick Ferris announced
The deadline for mentor signup has been extended to March 16th!
Research engineer or postdoc position at Inria Rennes: static analysis of OCaml programs
Benoît Montagu announced
Dear OCaml folks,
as part of a project between Inria and Lexifi, we are offering a 2-year research engineer or postdoc position, to work on the Salto static analyser for OCaml programs. The position can start anytime from spring 2026, and is located in the Épicure Inria research team, in the vibrant city of Rennes, France. If you have successfully defended a Ph.D. in computer science, and you are acquainted with the topic of static analysis, please contact me!
Experience with programming in OCaml or in another functional language is strongly recommended.
If you want to know more about this position, please have look at the detailed job description, and contact me!
Please feel free to transfer this announce to people that you think could be interested.
RFC: multifile ATD definition support via import statements
Archive: https://discuss.ocaml.org/t/rfc-multifile-atd-definition-support-via-import-statements/17881/1
Martin Jambon announced
Hello,
We're adding support for splitting ATD type definitions into smaller files. It wasn't possible to conveniently reference types defined from other ATD files until now, resulting in large interface files (example).
I would like a pair of eyes to help me check the sanity of the spec which is copy-pasted below from the pull request before this goes live in atd 4.0.0.
Import declarations
An ATD file may import other ATD modules using import declarations.
Import declarations must appear after any top-level annotations and before
any type definitions.
Syntax:
import module.path <annotations> as alias <annotations>
The as clause is optional. Without it, the local name of the imported
module is the last component of the dotted path (e.g. import foo.bar
binds the local name bar).
Type names from an imported module are referenced using dot notation:
alias.typename (or lastcomponent.typename when no alias is given).
For example, if a module types is imported, the type date from
that module is written types.date in type expressions.
Annotations on the path or alias allow language-specific backends to
override the module name used in generated code. The annotation
<ocaml name="..."> (or the equivalent for another target language)
on the path controls how the module is referenced in generated output,
while the same annotation on the as clause controls the local alias
name used in the generated code.
Examples:
(* Simple import: local name is "common" *)
import mylib.common
(* Import with an alias *)
import mylib.common as c
(* Using an imported type in a definition *)
type event = {
id : string;
timestamp : common.date;
}
(* Language-specific name annotation on the path *)
import mylib.common <ocaml name="Mylib_common">
(* Language-specific name annotation on the alias *)
import mylib.common as c <ocaml name="Common">
Warning:
Dotted module paths (e.g.
import foo.bar.baz) are an experimental feature. Each code generator maps them to file paths in its own way and there is currently no guarantee of consistent behavior across backends. When possible, prefer single-component module names (e.g.import bazorimport foo as bar). Support for dotted module paths may be removed in a future release.
Old CWN
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe to the caml-list.