The experience reports for ICFP are defined as:

The purpose of an Experience Report is to describe the experience of using functional programming in practice, whether in industrial application, tool development, programming education, or any other area.

Vpnkit is a tool used in the Docker 4 Mac stack to translate networking operations between the host (macOS) and the virtual machine (Linux). It is almost entirely written in OCaml making heavy use of the various Mirage libraries for building portable networking applications.

An interesting direction for this paper may be instead to focus on moving the OCaml ecosystem from one without algebraic effects, to a community with algebraic effects. Where this is most acutely felt is how libraries manage asynchronous IO. This almost feels like an ICFP paper in and of itself. A tentative structure could be:

1. Introduction to OCaml 5 work and effects.

2. Experiments pre OCaml 5, Eio.

3. Porting large applications (Irmin and Vpnkit) to Eio.

4. Current situation: algebraic effect-based zoo.

5. Future: Picos, Eio, etc.

This feels like a strong and interesting paper. Two key strengths are: a very measurable section at (3), very practical throughout etc.

It feels reminiscent of the Scala capability keynote from last year, but would be less technical?

The exact nature of this paper is a little unclear to me. But here goes.

Programming languages that do something must do IO. Operating systems present different mechanisms for doing IO. This paper would be looking at explaining these mechanisms and how they fit into a programming language (either poorly or well) and perhaps calling for better designs for languages as it relates to modern, post-POSIX IO.

On linux there are maybe two abstractions over system calls we may wish to discuss: AIO and Uring.

On macOS we have the Grand Central Dispatch.

What does this all boil down too? It might be interesting to describe these various models for achieving asynchronous IO:

1. Parallelism: one model is purely thanks to having multiple OS threads. In this model, you can block on an IO operation on a separate running thread.

2. Polling: this is your epoll, select() etc. Here, you make what would normally be considered blocking calls but only when you're pretty sure you know the call won't block.

3. Submission and Completion Queues: IOCP and Uring, this is a OS-provided mechanisms for submitting an IO operation and receiving completions when the kernel has performed the task. Conceptually, this is a lot simpler and shifts the burden of multiplexing IO on the kernel (you may have some parameter configuration to help you).