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 melange-str: Str module for Melange Outreachy May 2026 Research engineer or postdoc position at Inria Rennes: static analysis of OCaml programs RFC: multifile ATD definition support via import statements Old CWN Eliom 12: Client-server applications in Web Assembly ════════════════════════════════════════════════════ Archive: 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]. [main documentation page] [here] melange-str: Str module for Melange ═══════════════════════════════════ Archive: 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*: 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! [melange-str] Outreachy May 2026 ══════════════════ Archive: 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 ════════════════════════════════════════════════════════════════════════════════════════ Archive: 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. [Inria] [Lexifi] [Salto static analyser] [Épicure Inria research team] [detailed job description] [contact me] RFC: multifile ATD definition support via import statements ═══════════════════════════════════════════════════════════ Archive: 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. [ATD] [example] [pull request] 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 as alias 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 `' (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 │ │ (* Language-specific name annotation on the alias *) │ import mylib.common as c └──── 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 baz' or `import 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]. [Alan Schmitt] [send me a message] [the archive] [RSS feed of the archives] [caml-list] [Alan Schmitt]