[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

Alan Schmitt
2026-03-10T13:30:21Z

[-- Attachment #1: Type: text/plain, Size: 8948 bytes --]

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:
<https://discuss.ocaml.org/t/eliom-12-client-server-applications-in-web-assembly/17871/1>

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]
<https://ocsigen.org/tuto/latest/manual/basics>

[here] <https://ocsigen-1.inria.fr/ocsigen-start/demo/>

melange-str: Str module for Melange
═══════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-melange-str-str-module-for-melange/17877/1>

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!

[melange-str] <https://github.com/davesnx/melange-str>

Outreachy May 2026
══════════════════

Archive: <https://discuss.ocaml.org/t/outreachy-may-2026/17863/3>

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:
<https://discuss.ocaml.org/t/research-engineer-or-postdoc-position-at-inria-rennes-static-analysis-of-ocaml-programs/17879/1>

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] <https://www.inria.fr/>

[Lexifi] <https://www.lexifi.com/>

[Salto static analyser] <https://salto.gitlabpages.inria.fr/>

[Épicure Inria research team] <https://team.inria.fr/epicure/>

[detailed job description]
<https://jobs.inria.fr/public/classic/en/offres/2026-09842>

[contact me] <https://people.irisa.fr/Benoit.Montagu/>

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.

[ATD] <https://github.com/ahrefs/atd>

[example]
<https://github.com/semgrep/semgrep-interfaces/blob/main/semgrep_output_v1.atd>

[pull request] <https://github.com/ahrefs/atd/pull/451>

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 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] <mailto:alan.schmitt@polytechnique.org>

[the archive] <https://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>

[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>

[Alan Schmitt] <https://alan.petitepomme.net/>

[-- Attachment #2: Type: text/html, Size: 20078 bytes --]