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

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

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

Hello

Here is the latest OCaml Weekly News, for the week of March 24 to 31,
2026.

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

Improve signature-help feature in Merlin
Feedback Wanted: Upcoming OCaml Users Survey 2026 Questions
OCaml Users Survey 2023 Results
ortac-0.8 specification-driven testing with Domains
Third alpha release for OCaml 5.5.0
ocaml-openapi-gen 0.1.0, ocaml-forgejo
CS6868 Concurrent Programming – Course Materials
libinput - OCaml bindings for Linux input devices
OCaml compiler office hours
Old CWN


Improve signature-help feature in Merlin
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-improve-signature-help-feature-in-merlin/17920/1>


Charlène_Gros announced
───────────────────────

  We, at Tarides, are very happy to announce some improvements made to
  Merlin’s `signature-help' feature!

  As a reminder, `signature-help' is a feature in Merlin that displays
  the function signature and highlights the active parameter. In the
  editor, this is typically displayed in a tooltip, floating window, or
  minibuffer. For instance, the following image displays the
  `signature-help' for the function `exec_prog' in VSCode.

  <https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/4/46e99c5c69bab991b8dd6a6a7494db5c2f32e07b.png>

  The implementation of the signature-help command had a few
  shortcomings, which have been fixed. These fixes are making the
  feature way more pleasant to use. Some of these improvements are
  already part of the last Merlin and ocaml-lsp releases, others will be
  included in the next release.

  Results:

  • Merlin only displays `signature-help' information on the function
    parameters and no longer displays it on the function name.
  • `signature-help' displays the function's information only for the
    active parameters, and no longer loops back to highlight the first
    parameter after the last one.
  • `signature-help' is now triggered even if used inside a `let .. in'
    binding, in which the `in' is not yet written after the function
    call
  • The optional parameters are now detected and highlighted when the
    active parameter starts writing one.


Feedback Wanted: Upcoming OCaml Users Survey 2026 Questions
═══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/feedback-wanted-upcoming-ocaml-users-survey-2026-questions/17925/1>


Sabine Schmaltz announced
─────────────────────────

  Hi everyone, I am preparing the OCaml Users Survey 2026 on behalf of
    the OCSF and would like your input on the survey questions before we
    finalize them.

  You can find the proposed question list here: [Proposed OCaml Users
  Survey Questions 2026] For reference, there is a [summary of the
  changes compared to the 2023 survey].


[Proposed OCaml Users Survey Questions 2026]
<https://hackmd.io/3i-d6wgYRy2uVhqIVbxzNg>

[summary of the changes compared to the 2023 survey]
<https://hackmd.io/@sabine-s/BkVG6DWibg>

Summary of proposed changes since the 2023 survey
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  New sections:
  • AI/LLM Usage (4 questions) - Do you use AI/LLM tools for OCaml
    development? Which ones? What for?
  • Debugging & Profiling (3 questions) - What debugging approaches and
    tools do you use? What are the biggest challenges? (Motivated by
    frequent mentions of debugging difficulties in the 2023 free-text
    responses.)

  New standalone questions:
  • Community size preference ("I wish the community was…")
  • Documentation tools used (odoc, ocamldoc, etc.)
  • Dedicated free-text fields for tooling and package repository
    feedback

  Removed questions (10 total) - questions that yielded
  low-actionability data or were redundant, including: largest project
  size, release schedule satisfaction, source hosting platform, web
  deployment platforms, "OCaml tooling provides a comfortable workflow
  for me", "OCaml libraries are stable enough", "software written in
  OCaml is easy to maintain", and the language feature wishlist (effect
  handlers have shipped in OCaml 5).

  Modified questions - new answer options reflecting ecosystem
  evolution: OxCaml, Zig, Helix, Zed, WebAssembly targets, dune package
  management, Nix-based builds, Bluesky, and AI/LLM-related options in
  the "burning desires" section. Old compiler versions (4.02-4.06)
  collapsed into "≤4.07". Benchmarking tools now listed by specific name
  rather than category.

  We'd love your feedback on:

  • Are there questions you think should be added or removed?
  • Are any answer options missing?
  • Are there new topics that are important to the OCaml community that
    we should ask about?
  • Is the survey too long, too short, or about right at 58 questions?

  Thank you for helping us make the survey as useful as possible!
  :two_hump_camel: :orange_heart:

  Sabine

  PS: See also [the results of the OCaml Users Survey 2023]!


[the results of the OCaml Users Survey 2023]
<https://discuss.ocaml.org/t/ann-ocaml-users-survey-2023-results/17926>


OCaml Users Survey 2023 Results
═══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-users-survey-2023-results/17926/1>


Sabine Schmaltz announced
─────────────────────────

  Hi everyone,

  on behalf of the OCSF, I am happy to announce the (belated) report on
  the responses to the OCaml Users Survey 2023. We apologize for the
  delay in evaluating and are committed to run the OCaml Users Survey
  reliably in a yearly fashion from now on.

  Without further ceremony, here is the link to the report:

  <https://ocaml-sf.org/docs/2023/survey-results.html>

  We welcome any feedback on the report, discussion around the responses
  and numbers (please share your interpretations and opinions), or other
  commentary.

  Thank you to everyone who participated in the survey to help us better
  understand the state of OCaml and its ecosystem! :orange_heart:
  :two_hump_camel:

  Sabine

  PS: the 2026 OCaml Users Survey is coming up. We greatly value your
  input on [the feedback thread about 2026 survey question changes].


[the feedback thread about 2026 survey question changes]
<https://discuss.ocaml.org/t/feedback-wanted-upcoming-ocaml-users-survey-2026-questions/17925/1>


ortac-0.8 specification-driven testing with Domains
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ortac-0-8-specification-driven-testing-with-domains/17927/1>


Nicolas Osborne announced
─────────────────────────

  Hi! We, at Tarides, are very excited to announce the release of
  ortac-0.8.0 for specification-driven testing!

  `ortac' is a tool in the [Gospel] ecosystem. The core idea is to
  translate a subset of the Gospel specification language into OCaml
  code and use these translations to generate runtime checking.

  `ortac' has a plugin architecture. You can install it via opam:

  ┌────
  │ $ opam install ortac-wrapper    # install the wrapper plugin for runtime assertion checking, with all the other necessary parts (runtime and cli)
  │ $ opam install ortac-qcheck-stm # install the qcheck-stm plugin that generates QCheck-STM tests, with all the other necessary parts (runtime and cli)
  │ $ opam install ortac-dune       # install the dune plugin to generate dune boilerplate to use the two previous plugins
  └────

  This release focuses on making Ortac/QCheck-STM take advantage of more
  features from the QCheck-STM test framework: namely testing in a
  parallel context and flexibility of the command generation.

  You can take a look at the [documentation] that explains how it works.

  Regarding testing in a parallel context, with the introduction of the
  bug report feature in version 0.2 and the coverage of SUT-returning
  functions in version 0.4, it was not possible anymore to easily
  generate QCheck-STM tests in a parallel context (which is quite easy
  in hand-written QCheck-STM tests). This is now fixed!

  Information for the bug report are partly collected in the function
  doing the actual testing (comparing the results from the actual run
  and the results from the model). This means that implementing the bug
  report feature for the parallel testing requires to rewrite this
  function, which is the heart of QCheck-STM+Domains and what we are
  trusting when running the tests (the Trusted Testing Base if you
  will). In order to check that we keep the same behaviour, that the
  generated tests have the same semantic as corresponding hand-written
  QCheck-STM tests, we minimized the diff of the [commit] introducing
  the collection of the information so that the preservation of the
  logic is apparent (at the end of the day, human review is what we
  trust).

  Since version 0.4, SUT-returning functions are included in the
  tests. The newly created SUT is then added to the store of SUTs that
  are picked as argument for the next calls. The question here is what
  to do with them in a parallel context: We can't add a SUT created in a
  parallel branch in a global store, as it is not supposed to be shared
  between domains. We've chosen a simple design, where we stop storing
  newly created SUTs once we are in a parallel context. No worries,
  these SUT-returning functions will still be fully tested in the
  sequential part of the testing (in sequential mode and/or in the
  sequential prefix of the parallel mode).

  One of the power of the QCheck-STM test framework is the flexibility
  of its command generator. This flexibility comes from the `QCheck.Gen'
  API itself and from the fact that the QCheck-STM command generator is
  parameterized over the state of the current model (think generation of
  a `lookup' command for a key-value store, you want to be able to have
  a chance to generate a call that lookup a key that is actually
  associated to a value). An automatically generated command generator
  ought to be a bit naive. In order to mitigate this naiveté, we allow
  the user to provide:

  • weights to be applied to specific command generation, usefull for
    example to disable the generation of the `push' command on a [work
    stealing queue] on the domain that is not supposed to own the queue.
  • complete command generator implementation when the user wants to
    take advantage on the command generator being parameterized over the
    current state of the model.

  Happy testing!


[Gospel] <https://github.com/ocaml-gospel>

[documentation]
<https://ocaml-gospel.github.io/ortac/ortac-qcheck-stm/index.html>

[commit]
<https://github.com/ocaml-gospel/ortac/commit/ef8d598ccbd6c9987648e201ebffb6abb5a3d610>

[work stealing queue]
<https://ocaml-multicore.github.io/saturn/saturn/Saturn/Work_stealing_deque/index.html#val-push>


Third alpha release for OCaml 5.5.0
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/third-alpha-release-for-ocaml-5-5-0/17928/1>


octachron announced
───────────────────

  With the progress of the ongoing stabilisation effort for OCaml 5.5.0,
  we are happy to announce a third alpha release for OCaml 5.5.0.

  The missing second alpha was unreleased due to an unforeseen
  interaction between the relocatable compiler and bootstrapping. This
  issue is fixed in this third alpha.

  Beyond this important change, compared to the first alpha this new
  alpha release contains

  • two code generation fixes
  • three type system fixes
  • one standard library fix

  (see the Changelog below for a full list).

  Overall, it looks like 5.5.0 is stabilizing quite well and alpha
  versions of most development tools are available. Thus we are planning
  to switch to a beta release in the beginning of April.

  More precisely, the ongoing progress on stabilising the ecosystem is
  tracked on the [5.5.0 readiness meta-issueon opam].

  There is also a companion alpha opam repository available for this
  alpha release
  ┌────
  │ $ opam repo add alpha git+https://github.com/kit-ty-kate/opam-alpha-repository.git
  └────
  which contains in-progress alpha releases of opam packages that are
  being updated for OCaml 5.5.0 .

  The final release is still planned for between May and June.

  If you find any bugs, please report them on the [issue tracker].

  If you are interested by the full list of new features and bug fixes,
  the updated [changelog for OCaml 5.5.0] is available.

  Happy hacking, Florian Angeletti for the OCaml team


[5.5.0 readiness meta-issueon opam]
<https://github.com/ocaml/opam-repository/issues/29463>

[issue tracker] <https://github.com/ocaml/ocaml/issues>

[changelog for OCaml 5.5.0]
<https://github.com/ocaml/ocaml/blob/5.5/Changes>

Changes compared to the first alpha
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Compiler artefact fixes

  • More bootstrap-friendly relocatable compiler
  • A bootstrap to fix compiler-libs related issues reported by
    js_of_ocaml


◊ Code generation bug fixes

  • [#14583]: fix bug in linear scan spilling heuristic that in certain
    situations could lead to miscompilations.  (Nicolás Ojeda Bär,
    review by Vincent Laviron)

  • [#13693], [#14514]: s390x: fix heap corruption with
    libasmrun_shared.so caused by PLT lazy binding trampoline saving
    FPRs into OCaml's fiber stack.  Replace PLT calls with GOT-indirect
    calls in the s390x code emitter.  (Zane Hambly, review by David
    Allsopp and Xavier Leroy)


  [#14583] <https://github.com/ocaml/ocaml/issues/14583>

  [#13693] <https://github.com/ocaml/ocaml/issues/13693>

  [#14514] <https://github.com/ocaml/ocaml/issues/14514>


◊ Type system bug fixes

  • [#14434], [#14652]: Protect check_counter_example_pat against
    polymorphic types, restoring type soundness.  (Stephen Dolan and
    Jacques Garrigue, report and review by Alistair O'Brien)

  • [#14603], [#14604]: avoid Ctype.apply failures when mixing
    polymorphic types and unboxed constructors.  (Gabriel Scherer and
    Stefan Muenzel, report by Brandon Stride, review by Florian
    Angeletti)

  • [#14626], [#14675]: take in account module-dependent functions when
    determining if an optional argument is non-erasable.  (Alistair
    O'Brien and Florian Angeletti, review by Gabriel Scherer)


  [#14434] <https://github.com/ocaml/ocaml/issues/14434>

  [#14652] <https://github.com/ocaml/ocaml/issues/14652>

  [#14603] <https://github.com/ocaml/ocaml/issues/14603>

  [#14604] <https://github.com/ocaml/ocaml/issues/14604>

  [#14626] <https://github.com/ocaml/ocaml/issues/14626>

  [#14675] <https://github.com/ocaml/ocaml/issues/14675>


◊ Standard library fix

  • [#14635]: Fix a bug in `caml_floatarray_gather' that would cause the
    result of `Float.Array.sub', `Float.Array.append',
    `Float.Array.concat' (when empty) not to be equal to `[||]'.  (Marc
    Lasson, review by Gabriel Scherer)


  [#14635] <https://github.com/ocaml/ocaml/issues/14635>


◊ Documentation update

  • [#13590]: Document automatic command-line expansion of `*' and `?'
    wildcards by the runtime under Windows.  (Benjamin Sigonneau, review
    by Nicolás Ojeda Bär)


  [#13590] <https://github.com/ocaml/ocaml/issues/13590>


ocaml-openapi-gen 0.1.0, ocaml-forgejo
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-openapi-gen-0-1-0-ocaml-forgejo/17929/1>


Zoggy announced
───────────────

  Hello,

  I just made a first release of [ocaml-openapi-gen], a tool generating
  code from an [openapis] specification.

  The `openapi_gen' package is available from my [personal opam
  repository].

  This tool is used to generate code for [ocaml-forgejo], a library to
  interact with Codeberg and other forgejo-based platforms through the
  [provided REST API].

  The generated interfaces way evolve in the future.


[ocaml-openapi-gen] <https://zoggy.frama.io/openapi/>

[openapis] <https://www.openapis.org/>

[personal opam repository] <https://framagit.org/zoggy/opam-repository>

[ocaml-forgejo] <https://zoggy.frama.io/ocaml-forgejo/>

[provided REST API] <https://codeberg.org/api/swagger#/>


CS6868 Concurrent Programming – Course Materials
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-cs6868-concurrent-programming-course-materials/17932/1>


KC Sivaramakrishnan announced
─────────────────────────────

  I’m currently teaching a course called “CS6868: Concurrent
  Programming” at IIT Madras. The goal of the course is to teach
  concurrent and parallel programming using OCaml 5, and then introduce
  [OxCaml] for safe and fast parallelism. I’ve covered the OCaml 5
  parts, and will be starting OxCaml next. I thought it would be good to
  share the course materials with the community.

  <https://github.com/kayceesrk/cs6868_s26>

  CS6868 assumes knowledge of OCaml, which I cover in [CS3100: Paradigms
  of Programming]. This course includes a [YouTube playlist] with all
  the lectures, notebooks, and assignments.

  CS6868 builds the foundations of parallelism, reasoning about
  correctness through linearizability, parallel programming through spin
  locks, mutexes, condition variables, memory consistency models, and
  the basics of performance and non-blocking data structures (lock-free
  linked lists, queues, and stacks). Here, the course closely follows
  the book [The Art of Multiprocessor Programming]. All the code has
  been redone in OCaml 5. In addition to the book content, the course
  also covers the OCaml relaxed memory model. We also cover a fair bit
  of OCaml-specific tools here, including concurrent property-based
  testing using [qcheck-lin and qcheck-stm], and [data race detection
  using TSAN].

  Following this, the course covers the basics of effect handlers,
  following specific parts of [Control structures in programming
  languages: from goto to algebraic effects]. We then build a
  full-fledged Go-like, multicore-capable concurrent programming library
  with lightweight threads, buffered channels, selective communication
  (in the vein of [Concurrent ML]), nested parallel programming (as in
  [domainslib]), and basic asynchronous IO (as in [Eio]).

  There is a growing collection of [course projects], which should be
  doable if you’ve gone through the course materials. Let me know if you
  have ideas for course projects.

  The course tries to bring together the content from [many] [tutorials]
  [we] [have] done in the past. Let me know if you have feedback. I’m
  open to accepting PRs fixing small issues, but given that this is an
  ongoing course, any large PRs will likely not be accepted. I hope you
  will enjoy working through this as much as I had fun making it.


[OxCaml] <https://oxcaml.org/>

[CS3100: Paradigms of Programming]
<https://github.com/kayceesrk/cs3100_m20>

[YouTube playlist]
<https://www.youtube.com/watch?v=9R8Oim7YU20&list=PLt0HgEXFOHdkE-NTs87s7QjwYwqeihb-D>

[The Art of Multiprocessor Programming]
<https://shop.elsevier.com/books/the-art-of-multiprocessor-programming/herlihy/978-0-12-415950-1>

[qcheck-lin and qcheck-stm]
<https://github.com/ocaml-multicore/multicoretests/>

[data race detection using TSAN]
<https://ocaml.org/manual/5.3/tsan.html>

[Control structures in programming languages: from goto to algebraic
effects] <https://xavierleroy.org/control-structures/>

[Concurrent ML] <https://en.wikipedia.org/wiki/Concurrent_ML>

[domainslib] <https://github.com/ocaml-multicore/domainslib>

[Eio] <https://github.com/ocaml-multicore/eio>

[course projects]
<https://github.com/kayceesrk/cs6868_s26/blob/main/project_ideas.md>

[many] <https://github.com/ocaml-multicore/ocaml-effects-tutorial>

[tutorials]
<https://github.com/ocaml-multicore/ocaml5-parallelism-tutorial>

[we]
<https://github.com/ocaml-multicore/parallel-programming-in-multicore-ocaml>

[have] <https://github.com/ocaml-multicore/effects-examples>


libinput - OCaml bindings for Linux input devices
═════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-libinput-ocaml-bindings-for-linux-input-devices/17933/1>


Thomas Leonard announced
────────────────────────

  I'm pleased to announce the first release of [libinput-ocaml] (OCaml
  bindings for the libinput C library).

  libinput is used by applications such as Wayland compositors to access
  mice, keyboards, touch pads, etc.

  [Linux input devices (with libinput-ocaml)] explains how input devices
  work on Linux, and shows how to use the library to create a little
  game:

  <https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/8/87988f00d0f601de559c15f736118a8928c54664.png>


[libinput-ocaml] <https://github.com/talex5/libinput-ocaml>

[Linux input devices (with libinput-ocaml)]
<https://roscidus.com/blog/blog/2026/03/28/input-devices/>


OCaml compiler office hours
═══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-compiler-office-hours/17230/32>


Continuing this thread, gasche announced
────────────────────────────────────────

  I propose to hold OCaml compiler office hours on Friday April 3d,
  11:00-12:00 UTC (in local time, [date-range from=2026-04-03T11:00:00
  to=2026-04-03T12:00:00 timezone=UTC].)

  • [collaborative pad to prepare questions/topics]


[collaborative pad to prepare questions/topics]
<https://notes.irif.fr/ncfgJV9KRRGE5HUxvaKFww#>


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: 36132 bytes --]

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