OCaml Weekly News

When learning functional programming, one is often confronted with constructs derived (or not) from category theory. Languages such as Haskell offer very complete libraries to use them, and thus, facilitate their learning. In OCaml, it often happens that these abstractions are buried in the heart of certain libraries/projects (Lwt, Cmdliner, Bonsai, Dune etc.). This is why one of the objectives of Preface is to propose tools for concretising these abstractions, at least as a pedagogical tool.

Since OCaml allows for efficient imperative programming, Preface is probably not really useful for building software. However, we (the maintainers) think that Preface can be useful for a few things:

• technical experimentation with abstractions (especially those from the Haskell world) that allow programming in a fun style.
• As an educational tool. Many teaching aids generally only offer the minimal interfaces to these abstractions. Preface tries to be as complete as possible.
• It was a lot of fun to make. The last point is obviously the lightest but building Preface was really fun! So even if some people won't see the point… we had fun making it!

Let's imagine this scenario! Oh, there's this article that seems to describe quite precisely how to solve this complex problem, elegantly, using this collection of abstractions. After reading, the article is clear and I know how to use this collection of abstractions in practice. I would like to test it. Not having enough RAM to install Cabal, I decided to do it in OCaml. But as one abstraction leads to another, I am obliged to build an armada of things and I abandon my experimentation.

So now, rather than doing it, locally, for the understanding of an article, I add it in Preface.

The README is quite expansive on motivations and some design choices, but we have tried to add some concrete guides:

• Understanding the module breakdown of Preface
• Effect handling using Freer
• Error handling with Result/Validation and a Free Applicative

And in addition here is a project, by a friend of ours, that uses Preface, to build static blog generators (very original isn't it :P), the code is highly documented and can be an entry point into how to use it: Github repository of the project

Preface does not offer much that is new, but we have tried to make it user-friendly and to document as much as possible the code and design choices. It's a lot of fun to build… and it will probably be just as much fun to maintain.

We are extremely open to contributions and feedback.

And my last words will be a warm thank you to the OCaml ecosystem that has facilitated so much of our development: Testing with Alcotest and QCheck is a pleasure. Dune is a fast and pleasant build system. ODoc has allowed us to have more control over the generation of documentation, especially with the @inline comment (on includes) which allows signatures from different modules to be merged. And MDX which I did not know at all and which is used extensively for guides.

I hope you can find interest in this project! Good luck with the rest of the containment (for those concerned).

• https://icfp21.sigplan.org/home/ocaml-2021
• https://ocaml2021.hotcrp.com

• Thursday 20th May (any time zone): Abstract submission deadline
• Friday 18th July: Author notification
• Friday 27th August: OCaml Workshop

Presentations and discussions focus on the OCaml programming language and its community. We aim to solicit talks on all aspects related to improving the use or development of the language and its programming environment, including, for example (but not limited to):

• compiler developments, new backends, runtime and architectures
• practical type system improvements, such as GADTs, first-class modules, generic programming, or dependent types
• new library or application releases, and their design rationales
• tools and infrastructure services, and their enhancements
• prominent industrial or experimental uses of OCaml, or deployments in unusual situations.

Presentations will be held in the online format. Each presentation comprise a prerecorded presentation and an interactive live Q&A session after the talk. Each talk will be re-translated three times in different time zones. Session chairs and volunteers will assist the authors in preparing and casting the presentation. Each presentation will be made available through the ocaml.org website.

To submit a presentation, please register a description of the talk (about 2 pages long) at https://ocaml2021.hotcrp.com/ providing a clear statement of what will be provided by the presentation: the problems that are addressed, the solutions or methods that are proposed.

LaTeX-produced PDFs are a common and welcome submission format. For accessibility purposes, we ask PDF submitters to also provide the sources of their submission in a textual format, such as .tex sources. Reviewers may read either the submitted PDF or the text version.

A pre-recorded versions of accepted presentation shall be provided before August, 13th. Volunteers will provide technical assistance to authors as well as provide necessary feedback and ensure that all videos match our quality standards.

The ML family workshop, held on the previous day, deals with general issues of the ML-style programming and type systems, focuses on more research-oriented work that is less specific to a language in particular. There is an overlap between the two workshops, and we have occasionally transferred presentations from one to the other in the past. Authors who feel their submission fits both workshops are encouraged to mention it at submission time and/or contact the Program Chairs.

• Frédéric Bour, Tarides, France
• Cristina Rosu, Janestreet, UK
• Hakjoo Oh, Korea University, Korea
• Hugo Heuzard, Janestreet, UK
• Jeffrey A. Scofield, Formalsim, USA
• Jonathan Protzenko, MSR, USA
• Joris Giovanangeli, Ahrefs, Singapore
• Jun Furuse, Dailambda, Japan
• Kihong Heo, KAIST, Korea
• Kate Deplaix, OCaml Labs, UK
• Medhi Bouaziz, Nomadic Labs, France
• Simon Castellan, INRIA, France
• Ryohei Tokuda, Idein, Japan
• Vaivaswatha Nagaraj, Zilliqa, India
• Youyou Cong, Tokyo Institute of Technology, Japan

Please contact the PC Chair (Frédéric Bour) for any questions.

More specifically, a lot of work has been done on RFC 2045 & RFC 2046 (see RFC 7578 § 4) which describe the multipart format (found in emails and in HTTP/1.{0,1} requests when serializing a <form>).

From this work (~ 2 years), we decided to extract the parts allowing to manipulate a multipart/form-data content for HTTP/1.{0,1} responses (plus RFC 2183). This resulted in the creation of multipart_form.

This project is a cross between what many users have been waiting for (for CoHTTP and http/af), a knowledge of what exists and its limitations, and finally a development in the spirit of MirageOS.

The result is an API that is "full stream". Indeed. a question arose from the beginning, how to manipulate this format while:

• not having access to a file system (MirageOS)
• not exploding memory usage for file uploads

With the help of @Armael and the memtrace tool, we were able to implement and extend multipart_form so that it is easier to use and really ensures our original assumption about memory consumption.

So we experimented with use cases like uploading very large files. Here is the result that memtrace gives us with a 100Mb file:

The application tries to save the games in files. We use opium (and thus http/af) but tests were also done with CoHTTP. The code is available here for people who want to reproduce.

Finally, a major effort has been made in the documentation to explain in detail how to use multipart_form. Version 0.2.0 also adds a way to produce a multipart/form-data document (experimental) with the same constraints on memory usage.

I hope this work will be useful to a lot of people. The documentation is available here.