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

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 25494 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of September 29 to
October 06, 2026.

Table of Contents
─────────────────

tinybox: 150 classic games (Pong to Quake) and Apps, in OCaml, and more
IX, a full OS (kernel, toolchain, vcs, …) in OCaml
Michel Mauny, 1959-2026
dream-html 4.0.0
hegel-ocaml 0.25.0 - concurrent stateful property-based testing
Tutorial on GADTs
OCaml Compiler Implemented in C++: It's Not Just Faster—It Also Increases Trust
Conf.funcp.org is a scam OCaml conference
Vaast 0.0.0 + Design discussion
a2a SDK in OCaml
Old CWN


tinybox: 150 classic games (Pong to Quake) and Apps, in OCaml, and more
═══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-tinybox-150-classic-games-pong-to-quake-and-apps-in-ocaml-and-more/18569/1>


Yoann Padioleau announced
─────────────────────────

  Hi,

  I made something. Well Claude made something, my first vibe coded
  project :slight_smile: An ode to code, 150 classic video games (from
  Pong to Quake), 50 classic apps (from VisiCalc and TurboPascal to
  Office and Chrome), all playable online and you can also admire their
  tiny OCaml code.  repo: <https://github.com/aryx/ocaml-elm-playground>

  the tinybox web app to play:
  <https://aryx.github.io/ocaml-elm-playground/tinybox.html>


IX, a full OS (kernel, toolchain, vcs, …) in OCaml
══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ix-a-full-os-kernel-toolchain-vcs-in-ocaml/18570/1>


Yoann Padioleau announced
─────────────────────────

  Hi,

  It is my pleasure to announce IX, a full operating system written in
  OCaml (by Claude Code). It is a continuation of two of my past
  projects, principia softwarica and XiX.

  Repo: <https://github.com/aryx/IX>

  website: <https://aryx.github.io/IX/>

  You can even explore the codebase with a nice visualizer, codemapv2
  (itself a rewrite, using Claude, of two of my past projects, codemap
  and codegraph done while at Facebook):
  <https://aryx.github.io/IX/codemap.html> Some literate books
  explaining in detail the code will arrive soon.  Enjoy!


Michel Mauny, 1959-2026
═══════════════════════

  Archive: <https://discuss.ocaml.org/t/michel-mauny-1959-2026/18571/1>


gasche announced
────────────────

  Dear all,

  It is with great sadness that we (the OCaml Software Foundation) are
  sharing the news of the death of Michel Mauny, a long-time member of
  the OCaml community. Michel passed away on September 17th 2026 ([more
  information, in French]).

  During his career as INRIA research scientist, professor at ENSTA and
  CEO of Nomadic Labs, and among his many contributions, Michel:
  • co-authored in 1985 the paper that started Caml: "The Categorical
    Abstract Machine", Cousineau, Curien, Mauny ([PDF]) ;
  • actively contributed in the late 80s to the "Heavy Caml"
    implementation that predated Caml Light and OCaml ( see
    <https://ocaml.org/history> for more details ) ;
  • introduced stream parsers with Daniel de Rauglaudre ([1992 tech
    report]), designed and co-maintained the camlp4 preprocessor ;
  • wrote with Guy Cousineau the first book in English about OCaml, "The
    functional approach to programming" (1998) ;
  • taught (O)Caml in French universities and engineering schools
    throughout his career (Paris 7, Polytechnique, ENSTA) ;
  • advised several PhD students, including several who remained active
    in the OCaml community: Grégoire Henry, Çağdaş Bozman, Benoît Vaugon
    and Pierrick Couderc ;
  • created in 2001 the Caml Consortium, an earlier structure for
    industrial users to participate in and fund the development of OCaml
    at INRIA ;
  • created in 2018 the OCaml Foundation, with the more ambitious goals
    of collecting more funds to also support the broader OCaml software
    ecosystem. Michel had to leave the OCaml Foundation when he moved
    from INRIA to Nomadic Labs, and we try our best to follow his
    vision.

  This solemn moment is also an occasion to reflect on the rich history
  of our OCaml ecosystem, which grows by a collection of individual
  contributions. As we mark Michel’s passing, we celebrate and thank
  him, as well as the many individuals who dedicate their time and
  effort, often over decades, to building our programming commons.


[more information, in French]
<https://www.pfloic.net/P1230.aspx?IdPer=eynJZ8ADn&IdAN=Auto>

[PDF] <https://www.irif.fr/~scherer/doc/others/CAM-1985.pdf>

[1992 tech report] <https://inria.hal.science/inria-00074898/>


dream-html 4.0.0
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-dream-html-4-0-0/18573/1>


Yawar Amin announced
────────────────────

  Hi, dream-html 4.0.0 has been released to opam:
  <https://ocaml.org/p/dream-html/4.0.0>

  Repo: <https://github.com/yawaramin/dream-html> API docs:
  <https://yawaramin.github.io/dream-html/dream-html/Dream_html/index.html>

  Dream-html is a library for generating HTML, closely integrated with
  Dream. It can be used as an alternative to Dream’s built-in Embedded
  ML templating language and comes with all current htmx attributes
  defined out of the box.

  In this release, I made a few breaking changes (hence major version
  bump):

  • Raise exceptions on path parameter parse errors: instead of
    responding with 400 Bad Request. This allows you to hook in your own
    custom response by catching the parse exception.
  • Remove unused form decoder error keys: specifically
    `error_expected_int32' and `error_expected_int64' which are already
    covered by `error_expected_int'.
  • Finally, revert to the previous style of HTML generation, breaking
    lines at the start of each attribute instead of pretty-printing the
    HTML with indentation. This is done for performance reasons.

  Fixes:

  • Router matching on encoded values, eg
    `/accounts/%F0%9F%91%8D/versions/1' is now able to extract the
    second segment, `👍'.

  New additions:

  • Invoker API attributes
  • Some more SVG elements

  Finally, raised the minimum supported OCaml version to 5.3.0 because
  of ppxlib.

  Enjoy!


hegel-ocaml 0.25.0 - concurrent stateful property-based testing
═══════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-hegel-ocaml-0-25-0-concurrent-stateful-property-based-testing/18575/1>


Ethan Chou announced
────────────────────

  Hello, we excited to announce hegel-ocaml 0.25.0!

  Since our last announcement of hegel-ocaml 0.14.1, we've added
  concurrent stateful property-based testing and nondeterminism handling
  to Hegel. Stateful property based testing sequences actions (which we
  call rules) that mutate the state of some model and the system under
  test. The concurrent part comes from running rules concurrently. Hegel
  spins up some number of workers and distributes some number of rules
  to each worker. Rules within a worker run sequentially, but rules in
  different workers may run concurrently. Of course, this introduces
  nondeterminism since the workers can run in any order or suspend. To
  handle this, Hegel repeatedly replays failures and outputs the number
  of times the failure was reproduced. Nondeterminism handling can also
  be turned off, so any nondeterministic failure produces a flaky test
  error instead. Of course, running Hegel inside of [Antithesis] will
  give reproducible failures.

  For an example of concurrent stateful testing, see the [docs].

  The unique feature of Hegel concurrent stateful tests is the ability
  to pass in different concurrency capabilities. Workers can be on
  threads, domains, or anything of the [`Concurrency.t' type.] We have
  included a thread capability and domains capability for your
  convenience. Hegel defaults to using threads.

  With the [`hegel_jane_async'] sublibrary, Jane Street ecosystem users
  can also run sequential stateful tests whose rules are async
  (returning `unit Deferred.t').

  For OxCaml users, hegel-ocaml is fully compatible with OxCaml
  5.2.0-minus39. With the [`hegel_jane_concurrent'] sublibrary, OxCaml
  users can also pass in concurrency capabilities from the `Concurrent'
  library. and run concurrent async stateful tests with
  `hegel_jane_async'.

  Happy testing and contributing!


[Antithesis] <https://antithesis.com>

[docs]
<https://hegel.dev/ocaml/hegel/Hegel/Stateful#concurrent-stateful-testing>

[`Concurrency.t' type.]
<https://hegel.dev/ocaml/hegel/Hegel/Concurrency#type-t.spawn_join_n>

[`hegel_jane_async'] <https://hegel.dev/ocaml/hegel/hegel_jane_async>

[`hegel_jane_concurrent']
<https://hegel.dev/ocaml/hegel/hegel_jane_concurrent>


Tutorial on GADTs
═════════════════

  Archive: <https://discuss.ocaml.org/t/tutorial-on-gadts/14040/33>


Continuing this thread, Raphaël Proust announced
────────────────────────────────────────────────

  I've written a supplement to the tutorial:

  <https://raphael-proust.gitlab.io/code/gadt-what-about-phantom-types.html>

  It compares GADTs and Phantom Types. It includes a (compulsory?)
  mention of Tyxml in discussion of Phantom Types. If anyone has other
  good examples to share I might add them.


OCaml Compiler Implemented in C++: It's Not Just Faster—It Also Increases Trust
═══════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-compiler-implemented-in-c-its-not-just-faster-it-also-increases-trust/18576/1>


Michael Bacarella announced
───────────────────────────

  You're absolutely right to be skeptical of your compiler binaries. In
  this post, we'll explore how a comprehensive C++ reimplementation
  unlocks DDC verification for OCaml — while delivering meaningful
  compile-time improvements. 🚀

  —

  Wait! Don't leave yet! The rest of this was typed character by
  character by a human.

  We had some fun here recently talking about an unrelated project, [the
  OCaml runtime ported to Rust], and this led to an interesting
  side-channel discussion that surfaced a paper on [Debootstrapping
  without Archeology] by Nathanaëlle Courant, Julien Lepiller and
  Gabriel Scherer. I somehow had never come across this before!

  Background brief on trusting trust: once upon a time, UNIX god Ken
  Thompson trolled the world during an acceptance speech by asking
  "wouldn't it be *hilarious* if your beloved compiler authors had
  introduced a backdoor years (decades) ago that was still lurking
  today???" (paraphrased). The crux of the matter was that, to compile a
  C compiler which is implemented in C, you need an existing C compiler
  binary and that's an opportunity to introduce malware that wakes up
  when it recognizes it's compiling a target program (like `login').

  Ever since then, the infosec community has been… curious… about
  trusting trust and they breathed a huge sigh of relief when [David
  A. Wheeler proposed diverse double compilation (DDC)] as a
  mitigation. So, has anyone done this for our favorite language?

  Yes! In the Debootstrapping OCaml paper, the authors describe writing
  an OCaml interpreter in MiniML (an OCaml subset) and a compiler for
  MiniML in Scheme to do DDC, which proved that OCaml 4.07.1 has no
  trusting trust backdoors when compiling itself. But notice this part
  in their paper:

        If we assume unlimited work resources, tailored
        debootstrapping is a trivial problem: just port your
        programming-language implementation to another language
        that has already been debootstrapped (for example C). But
        this is a massive effort that may never happen in practice
        – especially as you have to first convince your language
        implementors to work in a different programming language.

  Tee hee.

  I present [this independent OCaml compiler implemented in C++]. It
  runs a OOMs faster than the MiniML/Scheme debootstrapper, solves DDC
  for OCaml 5.5.1 release (and 5.6+trunk), produces *identical* byte
  outputs to the OCaml compiler, and it even runs faster than the
  official OCaml compiler(!)

  *NOTE for quick skimmers*: this project does *not* make your OCaml
   programs faster. It may only let you compile OCaml programs faster.

  Regarding byte-identical outputs. There's a few documented minor
  divergences that could be closed if there's interest. The divergences
  do not preclude DDC and they're minor enough that I am claiming byte
  identical.

  Most importantly: because we have done DDC, we can conclude the OCaml
  5.5.1 (and 5.6+trunk) bootstrap has no back doors when compiling the
  compiler. Furthermore, because we *do* produce byte identical outputs
  as upstream, arguably no back door is lurking outside of the
  source-available views.[1]

  Regrettably, not only is there no backdoor in the OCaml compiler,
  there isn't even an easter egg. Sad! I would have at least snuck in
  something like `mb4c4rell4_waz_here', but that's probably why the good
  people behind OCaml have commit bits and I don't.


[the OCaml runtime ported to Rust]
<https://discuss.ocaml.org/t/a-line-by-line-translation-of-the-ocaml-runtime-from-c-to-rust>

[Debootstrapping without Archeology] <https://arxiv.org/pdf/2202.09231>

[David A. Wheeler proposed diverse double compilation (DDC)]
<https://dwheeler.com/trusting-trust/>

[this independent OCaml compiler implemented in C++]
<https://github.com/mbacarella/cxx-ocaml>

How to run DDC yourself
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Clone the repo `git clone https://github.com/mbacarella/cxx-ocaml' and
  follow the instructions in `cxx/DDC.md'.

  Install an opam switch that uses the C++-based OCaml compiler

  Do this to get a switch whose `ocamlc' and `ocamlopt' are the C++
  version.

  ┌────
  │ opam switch create cxx-5.5 --empty
  │ opam pin add -n ocaml-variants.5.5.1 'git+https://github.com/mbacarella/cxx-ocaml#cxx-5.5'
  │ opam pin add -n ocaml-option-cxx.1   'git+https://github.com/mbacarella/cxx-ocaml#cxx-5.5'
  │ opam install ocaml-option-cxx ocaml-variants
  │ opam switch set-invariant --packages=ocaml-variants,ocaml-option-cxx
  └────

  To check that you're actually running the C++ version, do `ocamlc
  -cxx-version'. The stock compiler stays available in the switch as
  `ocaml*.stock'.

  Requirements: clang++ 18 or newer, cmake, ninja, and libzstd's dev
  files.

  Don't @ me that this is all a big hoax because you're missing some
  dependencies. [We have all seen how that goes].


[We have all seen how that goes]
<https://github.com/anthropics/claudes-c-compiler/issues/1>


Next steps
╌╌╌╌╌╌╌╌╌╌

  Minimize the extra dependencies needed above, like swapping clang for
  gcc to match OCaml upstream.

  I've only tested this on x86-64 on Linux, so ARM64 is an obvious next
  addition. Also probably should add support for flambda.

  There's still some low hanging performance-fruit wins that don't
  involve doing anything too obscene[2] to go after.

  I'm happy to hear your feedback! We can chat here or on the OCaml
  Discord's `#ai' channel.

  Let me know what you'd like to see!


Benchmarks
╌╌╌╌╌╌╌╌╌╌

  Take these with a grain of salt. Benchmarks are easy to embarass
  yourself with. That said.

  My benchmark host was a Desktop Ryzen 9 7950X with 128GB of RAM
  running Linux.

  I'd prepare an opam switch with each compiler and all project
  dependencies first.

  The benchmark itself is a full build of awso, an AWS library that has
  coverage for all of 300+ AWS services, including some very huge
  auto-generated modules with ppx.

  It builds byte code, native and assembles a gigantic awso-cli that
  links every aws library. I timed `dune build' and took the best of 3.

  I think this is a good real world test because it contains about
  100,000 build artifacts and it was a major quality of life issue to
  both do full rebuilds every time I tinkered with something. opam-ci
  certainly didn't appreciate how huge it was either.

  dune selected up to 32 cores on my host.

  *Results*

  • ocaml 5.5.1: 4998.41s user 1016.62s system 1904% cpu 5:15.91 total
  • c++ocaml 5.5.1: 3281.87s user 990.02s system 1984% cpu 3:35.30 total

  As we can see, both the CPU time and wall clock time are lower in the
  C++ version. In terms of wall time we are 1.47x faster.

  Every build artifact is bitwise identical to upstream: .cmi, .cmo,
  .cmx, .o, .cma, .cmxa. So are executables built in the same switch (in
  the C++ switch the stock compiler is `ocamlopt.stock' and the C++
  version is renamed over `ocamlopt'). The one difference is the
  .cmt/.cmti files, which are used by editor tooling. They decode to the
  same data but stock OCaml's marshalling has a form of structural
  sharing we didn't completely reproduce the layout of.[3]

  Note there's more than just the ocaml compiler itself running a
  build. A ton of time is spent in the gcc toolchain (like `as'). The
  improvement in individual artifacts is more substantial than the wall
  clock time suggests, but it's also a lot more work to describe. So
  I'll leave that for later if anyone is interested.


AI disclosure
╌╌╌╌╌╌╌╌╌╌╌╌╌

  I obviously didn't implement an OCaml compiler in C++ myself. I used
  Claude Code. This wasn't easy for Claude either: it has been working
  on this project for 4 months now, though progress sped up between the
  releases of Opus 4.8, 5.0 and 5.5, with some guest appearances by
  Fable.


This is not an April fool's
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Don't confuse this with Stephen Dolan's troll, which [compiled OCaml
  into C++ template metaprograms]. Game respects game though.


[compiled OCaml into C++ template metaprograms]
<https://github.com/ocaml/ocaml/pull/14701>


Conf.funcp.org is a scam OCaml conference
═════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/conf-funcp-org-is-a-scam-ocaml-conference/18577/1>


Cuihtlauac Alvarado announced
─────────────────────────────

  This site:

  <https://conf.funcp.org/>

  Presents as an OCaml/Haskell/FP conference. However:

  • The event is not listed on the venue's official schedule:
    <https://www.javitscenter.com/calendar>
  • The funcp.org domain was registered two weeks ago, yet the oldest
    blog posts are dated from April: <https://rdap.org/domain/funcp.org>
  • The domain has no email routing — the contact addresses cannot
    receive mail: <https://mxtoolbox.com/emailhealth/funcp.org/>
  • Registration routes payment off-site to a third-party platform
    (gomry.com), with a $149+ ticket.
  • Listed speakers or organisers don't seem to have any track record in
    our community
  • Talk's topics don't stand scrutiny
  • Claims to be a second edition, but I can't find a prior edition

  If you registered, I suggest cancelling and getting your money back.

  This has been reported to the OCaml and Haskell security teams, the
  Javits Center, Google Safe Browsing, Cloudflare, dev.events (which
  lists the conference), and Gomry (the payment platform).

  Thanks to @adrien, @mtelvers and @edwin, who helped disclose this.


Vaast 0.0.0 + Design discussion
═══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-vaast-0-0-0-design-discussion/18583/1>


fantazio announced
──────────────────

  Hi all,

  This is a bit of mixed post.

  I am excited to announce the 1st prototype of [Vaast] !  Vaast is a
  library to handle multiple versions of the Typedtree at once. It is
  meant as a replacement for the current compiler-version-dependent
  techniques (be it preprocessing or branching).

  Similarly to ppxlib for the Parsetree, it provides a single
  representation of the Typedtree. Unlike ppxlib, it does not select a
  compiler version's representation but provides a form of
  super-representation which embeds the Typedtree from OCaml 4.14 to 5.5
  at once. It does so via a dedicated type encoding which explicitly and
  precisely identifies the differences in-between versions.Vaast's
  Typedtree representation is a shallow replacement for OCaml's
  Typedtree, making it cheap to use and easy to integrate incrementally
  in existing code.

  More details on its design are available on my blog:
  <https://fantazio.eu/articles/designing_vaast.html>

  This leads us to the second part of this post: discussing the design.
  The prototype is usable as a replacement for the compiler's Typedtree
  (and I [experimented it on the dead_code_analyzer]). Overall its
  design resembles the Typedtree but limits the breakages in user-code
  when updating to a more recent OCaml version.

  Here is an example of code in [odoc], relying on `cppo' to handle the
  different versions of the Typedtree:
  ┌────
  │ #if defined OXCAML
  │           | Tpat_alias (_, id, loc, _uid, _, _, _) -> (
  │ #elif OCAML_VERSION >= (5, 4, 0)
  │           | Tpat_alias (_, id, loc, _uid, _ty) -> (
  │ #elif OCAML_VERSION >= (5, 2, 0)
  │           | Tpat_alias (_, id, loc, _uid) -> (
  │ #else
  │           | Tpat_alias (_, id, loc) -> (
  │ #endif
  │               match maybe_localvalue id loc.loc with
  │               | Some x -> poses := x :: !poses
  │               | None -> ())
  └────

  And here is the equivalent using Vaast (and discarding the OxCaml
  case):
  ┌────
  │ | Tpat_alias {id; name; _} -> (
  │     match maybe_localvalue id name.loc with
  │     | Some x -> poses := x :: !poses
  │     | None -> ())
  └────

  There are some rough edges (`Texp_function', flattenable versioned
  types), and, before diving deeper into building the library, I would
  appreciate feedback and participation of those interested in its
  development and its use.  I opened a [dedicated issue] for that
  purpose.

  The mid-term goal is to add utility functions for usual operations,
  support a few mainstream modules of compiler-libs (`Parsetree',
  `Types'), and make Vaast a basic building block for static analyzers.
  The long-term goal is to interface most of compiler-libs.

  Thanks !


[Vaast] <https://github.com/fantazio/vaast>

[experimented it on the dead_code_analyzer]
<https://github.com/LexiFi/dead_code_analyzer/compare/master...fantazio:dead_code_analyzer:vaast>

[odoc]
<https://github.com/ocaml/odoc/blob/6dc58262b276af7e24b92ac5343b9f26d621122b/src/loader/typedtree_traverse.ml#L43>

[dedicated issue] <https://github.com/fantazio/vaast/issues>


a2a SDK in OCaml
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-a2a-sdk-in-ocaml/18584/1>


prudencio announced
───────────────────

  SDK for the A2A protocol WIP

  <https://github.com/GildedHonour/a2a>


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 #1.1.2: Type: text/html, Size: 39027 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 568 bytes --]