[Caml-list] PADI 2027 Call for Papers (March 2027, Kyoto, Japan)

# PADI 2027 Call for Papers

The First Workshop on Programming and the Arts, Design, and Interactivity
March 2027, Kyoto, Japan, co-located with ‹Programming› 2027
Workshop website: https://2027.programmingconference.org/home/padi-2027
Conference website: https://2027.programmingconference.org

## Overview

The Workshop on Programming and the Arts, Design, and Interactivity (PADI) aims to explore how software science techniques can be used in creative domains. The workshop brings together researchers and practitioners working at the intersection between programming and the arts.

## Submission Categories

We invite submissions in two categories. The page limits exclude references.

* Research papers: Submit a paper (5-12 pages) describing original work that has not been published elsewhere. The program committee will be instructed not to disadvantage short papers. The goal is that the paper's length feel natural.

* Hands-on submissions: Submit an extended abstract (1-2 pages) explaining how you will use the allotted time and what you want the audience to take away. Describe any audience participation and interaction as appropriate.

Submissions must be in English, anonymous, and formatted using the ACM sigconf style guidelines. The style files can be downloaded from https://www.acm.org/publications/proceedings-template. Please use the configuration \documentclass[sigconf,screen,review,anonymous]{acmart}.

Submissions are handled via HotCRP: https://padi27.hotcrp.com/.

Accepted submissions will appear in the ACM Digital Library as part of the ‹Programming› 2027 companion proceedings.

## Evaluation

The program committee will consider the following aspects when evaluating submissions: creative originality, how programming contributes to the work, reflection on the creative process, and potential to spark discussion and participation.

## AI Usage

PADI is a celebration of human creativity. Any use of generative AI should be consistent with that goal. For example, using AI to help with writing technical English is consistent with the goals, but submitting a work whose main output is simply prompted from an existing model is likely not consistent. Submissions should make the authors' own programming contribution clear and briefly disclose any use of generative AI that affects the content of the work.

## Attendance

In-person presentations are the default, but we allow remote participation upon request if it is not practical for you to travel to Japan. Registration is required for both formats.

## Important Dates

All dates are Anywhere on Earth (AoE).

* Submission deadline: December 1, 2026
* Author notification: January 7, 2027
* Workshop: March 15 or 16, 2027

## Organizing Committee

* Rose Bohrer (AIST, Japan)
* Youyou Cong (Institute of Science Tokyo, Japan)
* Iris Johnson (NHL Stenden University of Applied Sciences, Netherlands)

## Program Committee

* Kenichi Asai (Ochanomizu University, Japan)
* Jonathan Immanuel Brachthäuser (University of Tübingen, Germany)
* James McCann (Carnegie Mellon University, United States)
* Farhad Mehta (University of Applied Sciences Rapperswil, Switzerland)
* Mae Milano (Princeton University, United States)
* Chandrakana Nandi (Certora Inc., United States)

Please feel free to ask any questions via the contact form: https://2027.programmingconference.org/contact2/padi-2027-papers.

[Caml-list] FSCD 2027: First Call for Papers

======================================================================== CALL FOR PAPERS FSCD 2027 International Conference on Formal Structures for Computation and Deduction Radboud University Nijmegen, The Netherlands 23-26 August 2027 https://fscd-conference.org/2027 ======================================================================== FSCD (https://fscd-conference.org/) covers all aspects of formal structures for computation and deduction, from theoretical foundations to applications. Building on two communities, RTA (Rewriting Techniques and Applications) and TLCA (Typed Lambda Calculi and Applications), FSCD embraces their core topics and broadens their scope to closely related areas in logic, models of computation, semantics and verification in new challenging areas. ------------------------------------------------------------------------ IMPORTANT DATES ------------------------------------------------------------------------ All deadlines are midnight anywhere-on-earth (AoE); late submissions will not be considered. • Abstract: 19 April 2027 • Submission: 26 April 2027 • Author Response: 8-12 June 2027 • Notification: 28 June 2027 • Final Version: 10 July 2027 ------------------------------------------------------------------------ LIST OF TOPICS ------------------------------------------------------------------------ The suggested, but not exclusive, list of topics for submission is: 1. Calculi - Rewriting systems (string, term, higher-order, nominal, graph, conditional, modulo, infinitary, etc.) - Lambda calculus - Logics (first-order, higher-order, equational, modal, linear, classical, constructive, etc.) - Proof theory (natural deduction, sequent calculus, proof nets, etc.) - Type theory and logical frameworks - Homotopy type theory - Process algebras (synchronous, asynchronous, static and dynamic semantics with and without time, etc.) - Quantum calculi 2. Methods in Computation and Deduction - Type systems (polymorphism, dependent, recursive, intersection, session, etc.) - Induction, coinduction - Matching, unification, completion, orderings - Strategies (normalisation, completeness, etc.) - Tree automata - Model building and model checking - Proof search and theorem proving - Constraint solving and decision procedures 3. Semantics - Operational semantics and abstract machines - Game semantics and applications - Domain theory and categorical models - Quantitative models (timing, probabilities, etc.) - Quantum computation and emerging models of computation 4. Algorithmic Analysis and Transformations of Formal Systems - Type inference and type checking - Abstract interpretation - Complexity analysis and implicit computational complexity - Checking termination, confluence, derivational complexity and related properties - Symbolic computation 5. Formal Systems for Modelling and Verification - Machine learning algorithms - Neuro-symbolic systems - Certification - Security - Blockchain - Databases - Planning 6. Tools and Applications - Programming and proof environments - Verification tools - Proof assistants and interactive theorem provers - Applications in industry - Applications of formal systems in other sciences - Applications of formal systems in education ------------------------------------------------------------------------ PUBLICATION ------------------------------------------------------------------------ The proceedings will be published as an electronic volume in the Leibniz International Proceedings in Informatics (LIPIcs) of Schloss Dagstuhl. All LIPIcs proceedings are open access. ------------------------------------------------------------------------ SPECIAL ISSUE ------------------------------------------------------------------------ There will be a special issue of Logical Methods in Computer Science of selected papers. More details will be provided later. ------------------------------------------------------------------------ SUBMISSION GUIDELINES ------------------------------------------------------------------------ The submission site is: https://easychair.org/conferences/?conf=fscd2027 Submissions must be formatted using the LIPIcs style files and submitted via EasyChair. Submissions can be made in two categories: * Regular research papers are limited to 15 pages, excluding references and appendices. They must present original research which is unpublished and not submitted elsewhere. * System descriptions are limited to 15 pages, excluding references. Shorter papers are welcome and will be given equal consideration. A system description must present new software tools, or significantly new versions of such tools, in which FSCD topics play an important role. An archive of the code with instructions on how to install and run the tool must be submitted. In addition, a webpage where the system can be experimented with should be provided. Submissions must be unpublished and not submitted for publication elsewhere. They will be judged on relevance, significance, originality, correctness, and readability. Reviewers may consider material provided in appendices, but submissions must be self-contained within the page limit. If software or data is relevant to a paper, a link that provides access to the software/data must be provided to enable reproduction of results. One author of each accepted paper is expected to register and present the work in person at the conference. In case this is not possible, online presentation will be arranged, but in-person registration will still be required. ------------------------------------------------------------------------ BEST PAPER AWARD BY JUNIOR RESEARCHERS ------------------------------------------------------------------------ The programme committee will select a paper in which at least one author is a junior researcher, i.e. either a student or someone whose PhD award date is less than three years from the first day of the meeting. When submitting the paper, other authors should declare to the PC Chair that at least 50% of the contribution is made by the junior researcher(s). ------------------------------------------------------------------------ COMMITTEES ------------------------------------------------------------------------ Program Committee Chairs - Mariangiola Dezani-Ciancaglini (University of Torino, Italy) - Daniele Nantes-Sobrinho (University of Brasilia, Brazil) Program Committee - Sandra Alves (UPorto) - Takahito Aoto (Niigata University) - Mauricio Ayala-Rincon (Universidade de Brasilia) - Franz Baader (TU Dresden) - Luis Caires (Universidade NOVA de Lisboa) - Malgorzata Biernacka (University of Wroclaw) - Alejandro Diaz-Caro (Inria / LORIA & UNQ) - Andrej Dudenhefner (Dortmund University) - Santiago Escobar (Universitat Politecnica de Valencia) - Claudia Faggian (CNRS - Paris 7) - Maribel Fernandez (King's College London) - Yannick Forster (INRIA) - Simon Gay (University of Glasgow) - Samir Genaim (Universidad Complutense de Madrid) - Silvia Ghilezan (Novi Sad University) - Ekaterina Komendantskaya (Heriot-Watt University) - Dexter Kozen (Cornell University) - Temur Kutsia (RISC, Johannes Kepler University Linz) - Marina Lenisa (University of Udine) - Giulio Manzonetto (IRIF, Paris Cite University) - Sonia Marin (University of Birmingham) - Catherine Meadows (Naval Research Laboratory) - Jose Meseguer (University of Illinois Urbana-Champaign) - Aart Middeldorp (University of Innsbruck) - Samuel Mimram (Ecole Polytechnique) - Paliath Narendran (University at Albany--SUNY) - Naoki Nishida (Nagoya University) - Valeria de Paiva (Topos Institute, California) - Jorge Perez (University of Groningen) - Frank Pfenning (Carnegie Mellon University) - Christophe Ringeissen (INRIA) - Alwen Tiu (The Australian National University) - Stephanie Weirich (University of Pennsylvania) Conference Chair - Herman Geuvers (Radboud University Nijmegen, The Netherlands) Workshop Chair - Cynthia Kop (Radboud University Nijmegen, The Netherlands) ------------------------------------------------------------------------ INVITED SPEAKERS ------------------------------------------------------------------------ TBD ------------------------------------------------------------------------ VENUE AND DATES ------------------------------------------------------------------------ Radboud University Nijmegen, The Netherlands 23-26 August 2027 ------------------------------------------------------------------------ SPONSORS ------------------------------------------------------------------------ TBD ------------------------------------------------------------------------ CONTACT ------------------------------------------------------------------------ All questions about submissions should be emailed to: Daniele Nantes-Sobrinho (dnantes 'at' unb.br) Mariangiola Dezani-Ciancaglini (dezani 'at' di.unito.it) ========================================================================

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

OCaml Weekly News

Previous Week Up Next Week

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.

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!

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.

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.

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.

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) -> (

[Caml-list] PAgE'27 Call for Papers (co-located with POPL'27)

PAgE 2027 Call for Papers
https://popl27.sigplan.org/home/page-2027

PAgE (Principles of Agentic Engineering) aims to bring together the formal methods and AI communities to advance the principles of safe agentic engineering. It will feature peer-reviewed papers and invited talks from experts in the field. We welcome submissions describing research results, artifacts, datasets, case studies, and experience reports. Topics of interest include, but are not limited to:

• Specifications and type-safe interfaces for tool use
• Memory and state management for agents
• Reliability & groundedness in planning and tool use
• Static & dynamic analysis and verification of agentic plans
• Safe integration with software engineering workflows
• Testing and debugging of agentic workflows
• Runtimes, compilers and virtual machines for agentic programs
• Evaluation methods and benchmarks for trustworthy agents and agentic software, including safety, reliability, and cost/latency tradeoffs
• Safety, security, and privacy of multi-agent systems
• Neuro-symbolic and formal methods approaches for agent reasoning and control

We also welcome submissions that explore the use of AI agents in the research and development process itself, including agent-assisted ideation, implementation, experimentation, artifact generation, and writing. Such submissions should clearly describe the workflow used, the extent of human oversight, and any lessons learned regarding reliability, reproducibility, and safety.

We encourage submissions describing work in progress, position papers, experience reports, negative results (with detailed analysis and hypotheses for future improvements), demos, artifact or dataset descriptions, and talk proposals.

Accepted submissions will be presented at the workshop but will not appear in the ACM Digital Library. You are free to submit work for presentation that is or will be published elsewhere.

Please ensure that all submissions are anonymized for review. Submissions may be up to 8 pages, excluding bibliography, and should use the standard SIGPLAN conference two-column format.

[Caml-list] FPBT'27 Call for Papers (co-located with POPL'27)

Call for Papers

https://popl27.sigplan.org/home/fpbt-2027

We are excited to announce that the first annual Future of Property-Based Testing Workshop (FPBT'27) will be happening in Mexico City on January 12th (co-located with POPL'27)!

FPBT will bring together researchers and educators who work on and teach PBT to talk about what technical advances the research community should focus on in the coming years, and how we can best bring PBT to the next generation of software developers.

Submissions are open now (deadline October 23rd); see https://popl27.sigplan.org/home/fpbt-2027 for details.

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

OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of August 25 to September 01, 2026.

Table of Contents

• Unhandled: a static checker for unhandled effects in OCaml 5, and a negative result
• The series of mirage-crypto* releases
• Rpmfile 1.0.0 and Bytream 0.2
• oxbow, a dynamic tiling window manager for the Wayland compositor River
• cdp 0.1.0 - typed Chrome DevTools Protocol libraries for OCaml
• Hardcaml Networking Library - Toy Project
• FUN OCaml 2027 in Bangalore, Jan 25-26 - Time to Send Talk and Workshop Proposals - Until Sep 30
• ease-caml - Easing library for OCaml
• opam 2.6.0~alpha1
• Old CWN

Unhandled: a static checker for unhandled effects in OCaml 5, and a negative result

Archive: https://discuss.ocaml.org/t/unhandled-a-static-checker-for-unhandled-effects-in-ocaml-5-and-a-negative-result/18474/1

Manish Paul announced

OCaml 5's effect handlers are untyped: the compiler does not check that a performed effect is handled, so a missing handler compiles cleanly and fails at run time with Effect.Unhandled. We have been building a static checker for that, and we would like some criticism of it, particularly of the parts we think are weakest.

What it does. It reads the compiler's own .cmt files, infers a per-function effect set, propagates by call-graph fixpoint, subtracts effects discharged at handler sites, and reports every perform that can reach a program entry point unhandled. Findings come with a blame path from entry to perform, and with a generated witness program: we synthesise it, compile it, run it, and only report the finding as confirmed if the effect actually arrives at an outer boundary.

How it is tested. Differential testing against the runtime as oracle: a generator emits programs, and we compare the checker's prediction against what the compiled program actually does when executed. Over 1000 generated programs, 0 false negatives. Branch-free programs: 600, no false positives. Branching programs: 400, 5.3% false positives, from joining both arms of a conditional. The witnesses deliberately do not parse the crash message. Handy, since 5.4 stopped printing the effect payload for two of our test programs and nothing broke.

The negative result, which is the reason for this post. We wanted to show the checker catches crashes that really happened, so we built a corpus of commits that fixed documented Effect.Unhandled problems and analysed each parent commit. It caught 0 of 6. The cause turned out to be that the modules the bugs lived in never compiled in our environment, so the analyser was never shown the code. The batch runner now reports "out of scope" separately from "missed" for exactly this reason.

Then we ran it across every opam package depending on eio, eio_main, picos, domainslib, riot, moonpool or miou, giving 85 repositories after deduplicating by dev-repo. 38 of them built far enough to analyse, 3,881 modules in total, and the tool reported 31 escapes. Every single one was our own false positive. Four causes, each found by reading the code we had accused:

1. We modelled "calls anything under Eio." as "requires an Eio runtime". Wrong for constructors and vtable builders: Eio.Flow.Pi.source, Eio.Stream.create, Eio.Condition.create, Eio.Buf_read.parse_string_exn.
2. We applied that client-usage model to eio's own source, which is a category error. eio does not need an Eio runtime to define itself.
3. We did not see through application operators. let@ env = Eio_main.run in body is ( let@ ) Eio_main.run (fun env -> body), and with the operator opaque the head of that application is not Eio_main.run, so the scheduler boundary vanished and an entire program looked like it ran with no runtime. The fix is to read %apply and %revapply out of the value description, which would also cover @@, |>, and operators a project defines for itself.

4. We only recognised an Effect.Unhandled guard when it named the exception. picos writes it as a catch-all and says why:

   | exception _exn ->
       (* This should only happen when not running under a scheduler.
          However, we don't match on a specific exception, because it
          depends on the OCaml version. *)
   

   We had recorded the same observation independently, and then watched 5.4 stop printing the effect payload, which is the same problem from the other side.

Causes 1 and 2 are fixed and regression-tested in both directions. Causes 3 and 4 are diagnosed but not yet fixed: the attempt broke the test suite and we reverted it rather than ship a red one, so they are written up in docs/LIMITATIONS.md with the forester and picos source that produced them. Twenty-five escapes fixed, six remaining and explained.

Every escape this tool has ever reported on third-party code has turned out to be our own false positive. We have not found a real bug in anyone's code. We would rather say that plainly than imply otherwise.

If there is a transferable lesson it is probably that one: a checker pointed at real code for the first time is mostly measuring itself, and the only way to tell the difference is to read the source you just accused.

What we would like criticism of.

• Is the library-contract output useful to you? On picos it produces:

  module Picos
    Picos.Trigger.await                may perform {Picos.Trigger.Await}
    Picos.Fiber.current                may perform {Picos.Fiber.Current}
    Picos.Fiber.spawn                  may perform {Picos.Fiber.Spawn}
    Picos.Fiber.yield                  may perform {Picos.Fiber.Yield}
    Picos.Fiber.Maybe.to_fiber_or_current may perform {Picos.Fiber.Current}
    Picos.Fiber.Maybe.or_current       may perform {Picos.Fiber.Current}
    Picos.Fiber.Maybe.current_if       may perform {Picos.Fiber.Current}
    Picos.Fiber.Maybe.current_and_check_if may perform {Picos.Fiber.Current, ...unknown}
  
  module Picos_std_event__Event
    Picos_std_event__Event.sync        may perform {Picos.Trigger.Await, ...unknown}
    Picos_std_event__Event.select      may perform {Picos.Trigger.Await, ...unknown}
  
  module Picos_std_structured__Run
    Picos_std_structured__Run.spawn    may perform {Picos.Fiber.Spawn, ...unknown}
  

  ...unknown in a set means the contract is incomplete at that function because it calls something we have no .cmt for; we would rather show that than round it down to a clean-looking set.

  Is a machine-checked statement of "what this library asks its callers to handle" worth having in a README or in CI?

• What shapes do we miss? We know about effects performed inside effc branch bodies, dynamically built handler records, and closures that reach a call site through a data structure (no 0-CFA yet). We would like to hear about the ones we do not know about.
• The scheduler model, meaning which entry point installs handlers for which family of effects, is data rather than analysis, and lives in models/schedulers.conf. The eio entries are cited to specific lines. The riot, moonpool and miou entries are guesses and labelled as such. Corrections very welcome.
• Has anyone actually hit an Effect.Unhandled crash in production? We are short of real examples and would take any pointer, including "we hit it and the cause was something your design cannot see".

Requires OCaml 5.3 or later, since Texp_match only grows its effect-case list in 5.3. CI runs 5.3 and 5.4.

Repository: https://github.com/manishpaulish/unhandled

Happy to be told the approach is wrong.

The series of mirage-crypto* releases

Archive: https://discuss.ocaml.org/t/the-series-of-mirage-crypto-releases/18476/1

Hannes Mehnert announced

Dear everyone,

it is my delight to release mirage-crypto* in version 2.4.1 (https://github.com/ocaml/opam-repository/pull/30568). There have been a series of releases since late July with 2.2.0. The reasoning behind is that several people used LLM to find some issues in the implementation that we are fixing in the process. It is likely there'll be more releases. We try to limit the releases we cut during each month. Me as a maintainer of that package is as well at the edge of what I can do (time-wise – please consider donating at https://robur.coop/#contact or via GitHub spoinsors – in the case you use this piece of software). Even more appreciated would be jump in, read code, review pull requests when they come in, contribute code cleanups (please don't submit your LLM generated improvements directly, but do careful reviews of them). Especially since now everyone is on the red team.

The performance of mirage-crypto has decreased due to added checks, but only in a small margin as far as I can observe on hardware that I use. Feel free to conduct your own benchmarks (there is bench/speed.ml available), and propose improvements.

Now, the changes range between fixes and cleanups to has a published advisory. There's not always a clear border. The full list can be found in the CHANGES file, or in the commit history. I encourage everyone to update to the latest release, and not use any previous release. As mentioned, some advisories are out, and for other fixes we think they may not need an advisory (although it may be that other implementations issues advisories for such fixes, so please be careful – you can as well submit PRs to ocaml/security-advisories if you think some specific fixes are important enough to get an advisory).

The fixes in more detail follow. Thanks to Eric Ebinger, Thomas Gazagnaire, and Anil Madhavapeddy for the reports. And to Tarides for make it possible that I spend some time on reviewing, merging, and releasing mirage-crypto.

mirage-crypto-ec

• timing attack on NIST lookup tables https://osv.dev/vulnerability/OSEC-2026-17 https://github.com/mirage/mirage-crypto/commit/1a61aeee7f593ec067612df1739ec905eab0450f
• now uses blinding https://github.com/mirage/mirage-crypto/pull/285
• do not accept point at infinity as ECDSA key https://osv.dev/vulnerability/OSEC-2026-13 https://github.com/mirage/mirage-crypto/commit/ca84f5ee8ede80bd1dd2aa4cd7cc90197752184e
• return early from scalar_mult in ED25519 https://github.com/mirage/mirage-crypto/commit/3b4ba91799700561509d0c6a2de81ed249d7b2b1
• X25519 compare in constant time https://github.com/mirage/mirage-crypto/commit/1aa4cf5e4c92dcb3edfa83b971e569fa05b8f47d
• properly encode the compressed point 0 https://github.com/mirage/mirage-crypto/commit/94cba54d8dbb5701c3bd7e1317b3f3987c1871e2

mirage-crypto

• decrypt only after AEAD tag has been verified https://osv.dev/vulnerability/OSEC-2026-12 https://github.com/mirage/mirage-crypto/commit/25e7570aec91e092b347561c23f84b6ec39e7163
• more bounds checks https://github.com/mirage/mirage-crypto/pull/281 https://github.com/mirage/mirage-crypto/pull/290 https://github.com/mirage/mirage-crypto/commit/1f0bf67044e67cf6e46911fcd77a0ff706b6c3e7 https://osv.dev/vulnerability/OSEC-2026-15 https://github.com/mirage/mirage-crypto/commit/7b5650b72314d65602d0baccbf83ad3013cb37d4
• avoid unaligned access https://github.com/mirage/mirage-crypto/pull/292
• reject bad ChaCha20 keys https://github.com/mirage/mirage-crypto/commit/7f505b0dc232805c0c725e99b5fbfa49b1be7c7e
• avoid padding when adata is aligned https://github.com/mirage/mirage-crypto/commit/999cac90f0de1e4b36451807c0e0dbee6edfde06
• avoid too long CCM messages https://github.com/mirage/mirage-crypto/pull/304
• AEAD ciphers avoid counter wrapping https://github.com/mirage/mirage-crypto/pull/305 https://github.com/mirage/mirage-crypto/pull/306 https://github.com/mirage/mirage-crypto/pull/304

mirage-crypto-rng

• the entropy harvesting test is now executed at initialization time of mirage-crypto-mkernel and mirage-crypto-rng-mirage https://github.com/mirage/mirage-crypto/pull/282
• fix entropy source IDs https://github.com/mirage/mirage-crypto/commit/86161d1f51fd748038d917a69490eba714bb60d5
• urandom RNG make it so that a fork doesn't repeat numbers https://github.com/mirage/mirage-crypto/pull/302
• detect RDSEED properly https://github.com/mirage/mirage-crypto/commit/0f858a9e165c004e716761385284aadc119b7006

mirage-crypto-pk

• DSA avoid division by 0 https://github.com/mirage/mirage-crypto/pull/289
• RSA avoid Invalid_argument when message is 2 https://osv.dev/vulnerability/OSEC-2026-14 https://github.com/mirage/mirage-crypto/commit/a0f59a0c90eb067505b55a03d3bb104eacd6dd33
• fix hardcoded DH groups https://github.com/mirage/mirage-crypto/pull/297
• fix decoding of OAEP without a separator https://github.com/mirage/mirage-crypto/commit/eca6fb33e44bfa374d4c625fa6295670efe7040b

Rpmfile 1.0.0 and Bytream 0.2

Archive: https://discuss.ocaml.org/t/ann-rpmfile-1-0-0-bytream-0-2/18477/1

Mikhail announced

Yo!

I am happy to announce the first major release of the Rpmfile library (for parsing RPM files) and a minor update of the Bytream library (streaming bytes and crunching them last library).

let () = 
  let metadata = 
    In_channel.with_open_bin 
      "hello.rpm" 
      Rpmfile.Reader.from_channel_without_payload 
  in

  let name, release = Rpmfile.View.(name metadata, release metadata) in 
  Printf.printf "%s.%s\n" name release
  (* hello.1.3 *)

Changes

• Rpmfile reader has been moved from Angstrom library to Bytream library. The biggest change in this version is the start of using the Bytream library to read RPM files from input/output streams
• Added CPIO archive reader (does not automatically decompress RPM file's payload, you will need to do that yourself)

Not done yet

• Signatures verification
• Payload decompression
• Digests

oxbow, a dynamic tiling window manager for the Wayland compositor River

Archive: https://discuss.ocaml.org/t/ann-oxbow-a-dynamic-tiling-window-manager-for-the-wayland-compositor-river/18484/1

Cole announced

Hello!

I'm excited to share a project I've been working on for the past few months, oxbow.

It's heavily inspired by my time using dwm, with some ideas taken from other window managers like Hyprland and Niri. Features include:

• Per-tag configuration (layout, mfact, gaps, etc.)
• Tiling layouts including even, diminish, dwindle, spiral, deck, and monocle
• Niri-ish scrolling in four orientations
• "alt-tab"-like overview
• Pure floating layout; oxbow respects native drag and resize requests on windows, making floating mode feel more natural
• Popular dwm patches such as scratchpads, sticky windows, window swallowing, and gaps
• Regex-based window rules to configure initial tags, output, size, position, and more
• IPC control via oxctl to configure all of the above, query state, and subscribe to events

oxbow is packaged in opam, but you can also install it with Nix/NixOS.

You may notice this is my first post; that is because this project is my first venture into OCaml! I wrote oxbow to be the window manager I've always wanted, but also to learn OCaml. I've really enjoyed the experience, and I plan to use OCaml in a few other projects. I've done my best to take advantage of OCaml's strengths, but I'm fully open to any suggestions/PRs/etc. to improve the internals or any other aspect of oxbow.

Thank you for having me!

cdp 0.1.0 - typed Chrome DevTools Protocol libraries for OCaml

Archive: https://discuss.ocaml.org/t/ann-cdp-0-1-0-typed-chrome-devtools-protocol-libraries-for-ocaml/18486/1

Atlas07 announced

Hi everyone,

I'm happy to announce the first release of ocaml-cdp - typed OCaml libraries for the Chrome DevTools Protocol.

Why

CDP lets a program control a real Chrome: open pages, run JavaScript, take screenshots, render PDFs, watch network traffic. OCaml had no CDP library. ocaml-cdp fills that gap: it turns the official protocol definitions into typed OCaml modules, so the compiler checks every command, event, and field.

What you get

Three packages:

Package	Where	What it is
cdp	opam	Typed protocol domains: records, enums, commands, events, with JSON codecs. Transport-agnostic.
cdp-gen	opam	The generator CLI: protocol JSON in, OCaml out. Any revision, your own domain selection.
cdp-lwt	GitHub only for now (see below)	The client: launches or attaches to a Chrome and drives it over libcurl WebSockets.

cdp ships 10 domains (Browser, DOM, Debugger, Emulation, IO, Network, Page, Runtime, Security, Target); the generator covers all 58.

Here is the full round trip: launch a headless Chrome, open a page, read its title back:

let%lwt chrome = Cdp_lwt.Chrome.launch () in
let%lwt transport = Cdp_lwt.Curl_transport.connect ~url:chrome.ws_url () in
let connection = Cdp_lwt.Connection.create transport in
let call ?session command = Cdp_lwt.Connection.call connection ?session command in
let%lwt created =
  call (Cdp.Target.Create_target.command (Cdp.Target.Create_target.make_params ~url:"about:blank" ()))
in
let%lwt attached =
  call (Cdp.Target.Attach_to_target.command
          (Cdp.Target.Attach_to_target.make_params ~target_id:created.target_id ~flatten:true ()))
in
let session = attached.session_id in
let%lwt () = call ~session (Cdp.Page.Enable.command (Cdp.Page.Enable.make_params ())) in
let loaded = Cdp_lwt.Connection.next_event connection ~session Cdp.Page.Load_event_fired.event in
let%lwt _nav =
  call ~session (Cdp.Page.Navigate.command
                   (Cdp.Page.Navigate.make_params ~url:"https://ocaml.org" ()))
in
let%lwt _fired = loaded in
let%lwt evaluated =
  call ~session (Cdp.Runtime.Evaluate.command (Cdp.Runtime.Evaluate.make_params ~expression:"document.title" ()))
in

Why cdp-lwt is not on opam yet

cdp-lwt uses libcurl's WebSocket API through the curl bindings. That API is on ocurl's master branch, but not in any ocurl release yet. cdp-lwt builds fine from a clone (its opam file pins ocurl master). As soon as ocurl makes a release, cdp-lwt follows onto opam.

Hardcaml Networking Library - Toy Project

Archive: https://discuss.ocaml.org/t/hardcaml-networking-library-toy-project/18488/1

Bohdan Purtell announced

General Kenobi

Greetings.

My name is Bo Purtell, and I'm an aspiring senior at the University of Florida.

Wanted to share a little project I've been working on over the course of the last year being a small networking stack for the hardcaml ecosystem for hardware development with OCaml! The project is still in it's infancy stages right now, but I've validated out a 10/100Mb duplex interface with very loose IPv4 and UDP support, and I'm currently wrapping up a PCS layer for 64/66b BASE-R encodings for 10G applications. A tad limited with my servers getting moved all the way back to Florida (from Cali) though, and I lost one of my regression machines in the move so going to have to go dive into docker stuff again - bleh.

https://github.com/LeEmperor/hardcaml_networking

It's All Math

I fear that I cannot go back to writing SystemVerilog the same way anymore given the wonderful levels of abstraction that I was able to get away with in OCaml. I firmly believe that my thinking of how "state" is represented, and the fact that I could reach for mathematical terminology when I went to describe an OCaml construct helped me immensely in being able to reason about some of these systems as I was constructing them. Helps with verification to an extent too.

Challenges

The biggest challenge I faced was the structuring of my verification suites and testing. There are a few floating hardcaml projects around, but trying to integrate around the expect test framework was a tad difficult since said examples are quite poor in demonstrating re-usable architecture or integration testing. I had thoughts that Alcotest might be used for larger integration suites, but I feel it's philosophy goes against what a standard expect test is even shooting at doing. Ultimately, expect tests pushed me to Emacs (from Neovim), as expect tests and tuareg fit nicely together - if I had to go pasting s-expressions again from the terminal I probably would've imploded. The change is definitely interesting, but well worth it in terms of configurability and OCaml support.

Quickcheck tests were quite nifty as well, but I was flying completely blind on using those, as there are seldom examples for any properly-sized projects release. It was nice to see that alot of my own UVM-based idioms that I am familiar with translated somewhat well with the Observation.t and Snapshot.t formations, but it would still be nice to see what actual production-grade hardcaml verification looks like. Wish there were formal verif examples as well as I have been firmly grasped by the formal-verif-bug, but only a few dronings in dead branches were all I could muster.

In Space!

Truly a bummer that no functional languages will ever see industry use. With that in mind, after wrapping up a double-internship stint Spring & Summer I can finally claim that some nonzero amount of Hardcaml is flying in Space! If anyone has any questions feel free to shoot me a message here or on LinkedIn!

PS : if anyone is familiar with proper hardcaml-based verification, could I beg for a quick chat on how integration tests would even work with expect systems? Do I just chuck a gigantic 300-line s-expression into the expected field? Surely not. Does Alcotest even enter the vocabulary for such things then?

FUN OCaml 2027 in Bangalore, Jan 25-26 - Time to Send Talk and Workshop Proposals - Until Sep 30

Archive: https://discuss.ocaml.org/t/fun-ocaml-2027-in-bangalore-jan-25-26-time-to-send-talk-and-workshop-proposals-until-sep-30/18490/1

Sabine Schmaltz announced

Hi everyone!

We are super excited to announce that FP Launchpad is hosting FUN OCaml 2027 in Bangalore! This will be the very first edition of FUN OCaml (and the first major OCaml conference) in India.

FUN OCaml 2027 is a two-day open source hacking event dedicated to OCaml enthusiasts and professionals, focusing on the real-world impact of OCaml and bringing our global community together.

Event Details

• Dates: January 25-26, 2027
• Location: MLR Convention Centre, Brigade Millennium Campus, JP Nagar 7th Phase, Bangalore
• Format: Day 1 is dedicated to talks (including a keynote, live-streamed online), and Day 2 features hands-on workshops and collaborative hacking.

Call for Participation (CFP) is Open!

The call is open through September 30. We welcome submissions from all experience levels - whether you are a first-time speaker, industry practitioner, academic researcher, or open source maintainer.

Topics we are especially excited about:

• How you use OCaml in your business or personal projects
• OCaml libraries, frameworks, and tools in the ecosystem
• Hands-on demonstrations that inspire people to hack on Day 2
• Deep dives into actual code and the reasoning behind design decisions
• Experience reports and lessons learned

All talks will be live-streamed and uploaded to watch.ocaml.org and FUN OCaml's YouTube channel.

• Submit your proposal: https://fun-ocaml.com/ (or directly via the CFP submission link)
• Stay updated: Follow FUN OCaml on its various social channels and join the FUN OCaml Discord server (see website).

We can't wait to see your proposals and look forward to welcoming you to Bangalore!

Note: A major reason why we've chosen to host FUN OCaml in India this year is that we will (a) have an easy time getting the event fully booked, with both students and professionals, and (b) will be able to again afford high production quality recordings. We expect higher demand and more participants for the OCaml beginners workshop. At the same time, we understand that traveling to India is less ideal than traveling in the EU.

As a speaker, if there's any concern about funding travel, please check the box in the CFP form to apply for financial assistance. Also, send your proposals early, so that you can start visa application (we provide visa support) as soon as your session is accepted.

ease-caml - Easing library for OCaml

Archive: https://discuss.ocaml.org/t/ann-ease-caml-easing-library-for-ocaml/18494/1

Christopher Sumnicht announced

Hi everyone,

I am happy to introduce: ease-caml (on opam) - an easing library for OCaml.

Why?

In video games you often want to manage animations and transitions. Usually this requires deforming a floating point value from one value to another (often continuously) over time so that an object moves from one place to another. Such a deformation is often referred to as an easing or tween. It can be hard to keep track of tweens. In Lua, there are various libraries like hump.timer and Flux which help manage and organize the tweens you have made so you can easily create different kinds and have a single source of updating them. ease-caml is inspired by those libraries and is intended to help with OCaml game development.

Also, I mentioned games above: Whether you use SDL, Raylib, or pretty much anything else, you can use this library. It just requires an update loop.

Example

Here is a small example of a bouncing ball (uses raylib-ocaml).

type circle =
{
  r: float;
  x: float;
  y: float ref;
}

let ball : circle = { r = 40.0; x = 400.0; y = ref ~-.40.0 }
let ty = Tween.make_tween ball.y 225.0 ~ef:Easers.bounce 1.0
let tm = Tween.new_manager ()

let setup () =
  Raylib.init_window 800 450 "simple_tween";
  Raylib.set_target_fps 60;
  Tween.add ty tm

let rec loop () =
  if Raylib.window_should_close () then Raylib.close_window ()
  else (
    let open Raylib in
    Tween.update tm (get_frame_time ());
    begin_drawing ();
    clear_background Color.raywhite;
    draw_circle_v (Vector2.create ball.x !(ball.y)) ball.r Color.maroon;
    end_drawing ();
    loop ()
  )

let () = setup () |> loop

(Note as a new user I cannot put more than 2 links. If you need help finding hump.timer, Flux, or raylib-ocaml, please let me know!)

opam 2.6.0~alpha1

Archive: https://discuss.ocaml.org/t/ann-opam-2-6-0-alpha1/18372/4

Continuing this thread, Kate announced

Hot on the heels of beta1, we are happy to announce the release of opam 2.6.0~beta2.

This version is a beta, we invite users to test it to spot previously unnoticed bugs as we head towards the stable release.

Main changes compared to 2.6.0~beta1

:hourglass_done: The main change is a fix of a performance regression compared to opam 2.5, where opam project trees were scanned for nothing, when pinning them, making commands such as `opam install –deps-only .` excruatingly slow on large projects (#7098)

:open_book: You can read our blog post for more information about these changes and more, and for even more details you can take a look at the release note or the changelog.

Try it!

The upgrade instructions are unchanged:

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.6.0~beta2"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.6.0~beta2"

Please report any issues to the bug-tracker.

Happy hacking, <> <> The opam team <> <> :camel:

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

[Caml-list] TFPIE 2027 Call for Papers (March 2027, Kyoto, Japan)

-------------------------------------------------------
Call for Papers
TFPIE 2027: The 16th International Workshop on
Trends in Functional Programming in Education
March 12th 2027, Kyoto, Japan, co-located with TFP 2027
https://wiki.tfpie.science.ru.nl/TFPIE2027
-------------------------------------------------------

## Topics

TFPIE welcomes submissions describing classroom techniques, classroom tools, and creative uses of functional programming (FP) to aid education in or outside computer science. Topics of interest include, but are not limited to:

* FP at different levels (high school, first-year and advanced undergraduate, graduate)
* FP and the arts (incl. music, animation, games, philosophy and other liberal arts)
* FP and applications (in computer science, robotics, artificial intelligence, etc.)
* FP and pedagogy (incl., e.g., computational thinking, e-learning, automated assessment)
* FP for building student engagement in research

In addition to papers, we invite best-lecture presentations. These are an opportunity to share your favorite classroom moments. Show us your favorite material or favorite way of presenting it. For best-lecture presentations, please submit a short abstract describing the lecture and its interest to TFPIE attendees.

## Submission Instructions

Submission is via EasyChair:

https://easychair.org/my/conference?conf=tfpie2027

Authors of papers have the choice of having their contributions formally reviewed either before or after the workshop. Further, pre-workshop submissions may either be full (earlier deadline) or draft papers (later deadline). See below for more details.

Accepted papers from the pre-workshop and post-workshop formal review will appear in a formal proceedings, published in the Electronic Proceedings in Theoretical Computer Science (EPTCS).

Reviewing is single-blind.

### Pre-workshop formal review

Papers to be formally reviewed before the workshop should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the workshop. A paper that has been rejected for publication but accepted for presentation may be revised and resubmitted for the post-workshop formal review. A paper that has been rejected for presentation will not be formally reviewed by the PC.

### Post-workshop formal review

Draft papers will receive minimal reviews and notification of acceptance for presentation at the workshop. Authors of draft papers will be invited to submit revised papers based on the feedback received at the workshop. A post-workshop refereeing process will then select a subset of these papers for formal publication.

### Formatting requirements

Papers must be written in English, and formatted using the EPTCS style (https://style.eptcs.org/). Papers submitted for formal review must be submitted as full papers (7-20 pages). Draft papers may be submitted as extended abstracts (4-6 pages) or full papers (7-20 pages). The page limits do not include bibliography. For best-lecture presentations, we also accept short abstracts.

If you wish to make a submission outside the above formats, please contact the PC chair to discuss. Because TFPIE aims to encourage creative and experimental research ideas, we may be able to accommodate some non-traditional submissions on a case-by-case basis.

## Important Dates

All deadlines are Anywhere-on-Earth.

* Submission deadline (pre-workshop full papers): November 19, 2026
* Notification (pre-workshop full papers): December 17, 2026
* Submission deadline (pre-workshop draft papers): February 4, 2027
* Notification (pre-workshop draft papers): February 11, 2027
* Submission deadline (post-workshop review): April 8, 2027
* Notification (post-workshop review): May 12, 2027

## Program Committee

* Youyou Cong (chair) - Institute of Science Tokyo, Japan
* Hsiang-Shang 'Josh' Ko - Academia Sinica, Taiwan
* Jens Mönig - SAP, Germany
* Paige Randall North - Utrecht University, Netherlands
* Liam O'Connor - Australian National University, Australia
* Joe Gibbs Politz - University of California at San Diego, USA
* Katsuhiro Ueno - Niigata University, Japan