OCaml Weekly News

I’ve just released iostream 0.1. iostream is a library that provides composable abstractions for input/output streams of bytes. Here composability means that users can create their own streams, which makes a Iostream.Out.t more powerful than the standard out_channel because it is an abstraction that might perform compression before writing to a Buffer.t, or writes to a socket, or write nowhere, or send the bytes to multiple other outputs.

There already exist some similar abstractions in the ecosystem, such as Batteries’ BatIO, an object based version of this in ocamlnet, and probably uncountably many other projects. I have ancestor versions of this in many of my own projects. This is my way of dealing with my failure to implement RFC19 in OCaml itself (a worthy read about tradeoffs and use cases, for anyone interested). In other languages you can find Rust’s Read, BufRead, and Write traits; and Go’s Reader and Writer interfaces.

A design note: in iostream there is a separation between Iostream.In.t (which is basically like a unix FD or rust’s Read: it gives you read: bytes -> int -> int -> int), and Iostream.In_buf.t (the equivalent of rust’s BufRead: it has its own buffer and gives you access to it. Unlike in_channel’s magic methods for input_line, you can inspect the buffer to look ahead and consume exactly the amount of input you need, no leftovers).

The library is under the MIT license. The online docs are here.

Looks like an interesting library to me. I have a few comments or questions:

1. Is there going to be support for bigarrays or do you not support them on purpose?
2. The documentation states that close “must be idempotent” for output streams and is “idempotent” for input streams. Could you clarify the distinction here? Also, did you consider just making sure that your modules never call these functions more than once? Seems like that would be more helpful to users of the library.
3. Did you consider splitting the parts that depend on Unix into a sub library?

These are good questions, thanks. It’s not easy to write interfaces with such a general purpose scope :sweat_smile:

1. I didn’t see a good way to support both bytes and bigarrays in the same interface ­— asking implementors to have both read and read_bigstring would be annoying, for example. However a good chunk of the ecosystem does rely on bigarrays so it is an important topic. I can imagine two solutions on the top of my head:
   • have read_bigstring, write_bigstring with default implementations just going through an intermediate layer of bytes, and the possibility for the implementor of the stream to write a custom version
   • parametrize the stream types with the underlying type, i.e have bytes Iostream.In.t as well as bigstring ~Iostream.In.t. But here the difficulty is that all the convenience combinators in the library become impossible to write, or specialized just for (say) the bytes version.
2. close should be idempotent for both, i.e closing twice shouldn’t fail. The reason is that it’s just too hard to keep track of whether you closed already, especially if you mix explicit closing (closing a connection) with resource handlers such as with_in : … or Fun.protect that will ensure proper disposal of resources.
3. How do you provide an interface with a as_fd : unit -> Unix.file_descr option in a sub-library? It has to be part of the core interface, or not be there at all. This part comes from the initial goal, in RFC 19, to replace standard channels (which provide things like seek and pos), but I agree it’s annoying to depend on Unix.

In the last two weeks, two significant bugs have been discovered in the release candidate for OCaml 5.1.0 (one affecting the type system, another in the runtime).

Those bugs are now fixed and we are publishing a second release candidate to check that everything is in order before the release in the upcoming week.

If you find any bugs, please report them on OCaml’s issue tracker.

The full change log for OCaml 5.1.0 is available on GitHub. A short summary of the two fixed bugs in this release candidate is also available below.

It is my pleasure to announce a new release of OCamlGraph, a graph library for OCaml. It is already available in opam and it is documented here.

Among other things, this release fixes an embarrassing bug in functions Dfs.fold and Dfs.fold_component, which were actually not implementing a depth-first traversal (yet a graph traversal). See the excellent post Stack-based DFS is tricky to get right for an explanation.

Note: We have deprecated the support of package ocamlgraph_gtk, a tool to display graphs using GTK. If you are using this package, please make an issue and we’ll discuss the options.

Hello everyone, I am excited to announce the release of my first OPAM package liquid_ml. Shopify’s Liquid Templating language for OCaml. Check it out here: https://github.com/benfaerber/liquid-ml

Learn Liquid syntax here: https://shopify.github.io/liquid/

The Liquid templating language is used all over including Shopify and Github pages. The Rust port of the language is very popular for static site and documentation generation. If anyone has any suggestions or wants to help improve the project I welcome pull requests!

Moonpool 0.4 was released on opam a few days ago.

There are not a lot of new features, but Moonpool is now a better citizen wrt resource usage: if no pool is active, background domains will shut down (to be spun back again later if they’re needed). This was trickier to get right than I expected and a last bug was found during the release process and fixed with the help of @avsm, @dra27 and Mark Telvers).

We just posted the thrilling conclusion to our blog trilogy on Oxidizing OCaml, which talks about some of the things we’ve been working on (and some of our space-age plans) around extending OCaml to support some of the same kinds of things that Rust lets you do, but in a distinctly OCaml-ish way.

Here are the posts:

• Locality
• Rust Style Ownership
• Data Race Freedom

Maybe more excitingly, you can play around with the version of our internal compiler that has the bits of this we’ve implemented thus far (mostly, the local/global stuff, but the beginnings of uniqueness as well) as well as our open-source libraries, via an opam switch.

This is very much a bleeding-edge, unstable version. We use it internally for real work, but we refactor it mercilessly, and the language features are most definitely not stable. We hope one day to propose a lot of this upstream, but for now, it’s just a preview of some interesting experiments.

The thing I’m most excited about all of this is the prospect of data-race free OCaml. The ability to leverage the great work done by the Multicore team, but safely, is a prospect I’m very much looking forward to.

Also, a bunch of Jane Street compiler folk will be at ICFP next week. If you’re interested in learning more, that’s a good time to grab one of us.

With the conclusion of the previous Outreachy round (see https://discuss.ocaml.org/t/end-of-internship-demo-session/12927/), the next round is fast approaching and the OCaml community has signed up again to participate!

The deadline for mentors to signup is September 29 2023. The OCaml community has decided to try a slightly different approach that has worked very well in the previous round. We noticed quite a few people would like to be involved in an internship but without worrying too much about the details of Outreachy itself. If people are simply interested in mentoring and they maintain an open-source project, then they can reach out directly to @pitag or myself and we can help scope a project, explain the contribution period and provide as much other help as we can!

When signing up mentors propose an open-source project where prospective interns submit PRs during the “contribution phases” as part of their application. Mentors will then choose an intern to work with for 3 months. A more detailed explanation is available on the Outreachy mentor section.

Finally, Tarides and OCaml Software Foundation have been very generous so far funding our efforts on the intern side. Since the previous round, Jane Street and Tarides have gone a step further and have also provided funding for the mentor side! Mentoring does take time, but you get a lot back from it on different levels and hopefully this financial help can lower the barriers to being a mentor.

As always if you have any general questions or mentoring ideas do comment on this thread or reach out to us directly.

It is my pleasure to announce a new release of PPrint, the pretty-printing library, with the following additions:

• The new function is_empty allows testing (in constant time) whether a document is empty.
• Documentation: add a warning about the time and space complexity of a naive use of ifflat.

The library now requires OCaml 4.03 or newer.