OCaml Weekly News

The Day of the Camel 2022 is a one-day hybrid workshop dedicated to the OCaml programming language and its industrial users.

It comprises talks and discussions with members of the OCaml development team and companies using the language to solve complex and interesting problems.

We will present a broad picture of the OCaml ecosystem and, more widely, of functional programming as a viable and powerful choice for building correct and reliable computer systems.

The event is organized as part of an OCaml summer school at the University of Zaragoza, and sponsored by the OCaml Software Foundation.

Participation is free and open to everyone. For more details about the schedule, updates and links to the online seminar, see the website:

https://webdiis.unizar.es/evpf/event.html

9 September 2022, all times CEST (UTC+2)

Morning - Language session

Afternoon - Industry session

We look forward to seeing you there!

Quick correction: Paul-Elliot Anglès d’Auriac from Tarides will be presenting instead of Ulysse. :slight_smile:

In the Octez project we have face a similar issue: we use both Lwt and Result pervasively.

TL;DR:

• We use dedicated syntax module for each monad (Lwt, result, Lwt+result) which export binding operators (let*, let+, return, etc.).
• We have a Stdlib supplement exposing monadic variants of all the Stdlib’s traversal functions (like Lwt_list but much more extensive)

We use dedicated syntax module for each monad (Lwt, result, Lwt+result) which export binding operators (let*, let+, return, etc.).

Brr uses the same approach for its futures which are used to FFI with JavaScript promises (these are not called promises because they don’t directly map on JavaScript promises as those have a non-monadic semantics which would break OCaml type safety).

Basically you have futures, future results and two syntaxes to choose from depending on your context.

I quite like the trace idea - I wish I’d thought of this for our codebase, but it would require too many changes in the calling code to adopt now. We just use string for the error type in our codebase and I’m not entirely satisfied with the “just pick the first error / fail fast” semantics I proposed for and* in Lwt_result.Syntax. Another choice might even have been to parametrize the Syntax module over desired behavior of how to combine concurrent errors, but we decided against it to avoid having to invoke a functor repeatedly all over the code (we’re already quite verbose - we don’t do global opens, and try to be explicit, e.g: let open Lwt_result.Syntax in - to know exactly which monad we’re talking about).

Implementation details on our side:

• We do have a functor for Tracing which is parametrised by an implementation of trace.
• We only initialise it once in the production part of our code-base. We also initialise another time for some tests.
• We provide examples for trace implementations including a version that gives you the left-most error.

I’d say that string is quite manageable for error management. If you want to structure it a bit more you can mash strings together a bit. Something like

val trace : string -> ('a, string) result -> ('a, string) result
let trace high_msg = function
  | Ok v -> Ok v
  | Error low_msg ->
    (* indent all of the local errors *)
    let low_msg = "\t" ^ String.concat "\n\t" (String.split '\n' low_msg) in
    (* layout high error and low error *)
    Error (Printf.sprintf "%s\n%s" high_msg low_msg)

val parmash : ('a, string) result list -> ('a list, string) result
let parmash rs =
  let rec loop acc = function
    | (Ok v) :: xs -> loop (v :: acc) xs (* accumulate Oks *)
    | (Error msg) :: xs -> loop_err [msg] xs (* Switch to err loop on first Error *)
    | [] -> Ok (List.rev acc) (* just return accumulated Oks *)
  and loop_err acc = function
    | Ok _ :: xs -> loop_err acc xs (* Discard Oks *)
    | Error msg :: xs -> loop_err (msg :: acc) xs (* Accumulate Errors *)
    | [] -> match acc with
        | [] -> assert false
        | [msg] -> Error msg (* single error: return as-is *)
        | _ :: _ :: _ as msgs ->
            (*multiple errors: pretty-print with separators *)
            Error ("|" ^ String.concat "\n|" (List.rev msgs))
    )
  in
  loop [] rs

Or something along those lines. And then and* calls parmash on the resolved promises to make line-separated |-prefixed error messages.

Basically you end-up just doing the printing of the trace in advance. And it’s heavier than to carry a type trace = Nest of string * string trace | Par of string trace list | Leaf of string and do the printing only once. Plus you can’t have fine control over the printing like hbox and vbox. But it might be acceptable if the errors are truly the exceptional case and you don’t have too many levels of them.

[this post is about a new French-speaking OCaml meetup group in Toulouse, thus the remainder of the text will be in French]

Bonjour à tous les cameleux toulousains !

Ma collègue @rjbou et moi-même mettons en place un meetup group OCaml à Toulouse.

S’inspirant des meetups “OUPS” à Paris, nous avons souhaité créer un événement similaire à Toulouse. L’objectif de ces meetups est de rassembler des personnes aux profils variés, qu’ils soient utilisateurs débutants ou chevronnées d’OCaml (développeurs, chercheurs…), ou qui souhaitent simplement découvrir ce langage. Les orateurs sont invités à présenter un sujet qui leur plaît, qu’il s’agisse d’une nouvelle librairie ou un nouvel outil, les nouvelles fonctionnalités du langages, des travaux de recherche, un bout de code amusant (liste non exhaustive)… Ces meetups se termineront par des discussions autour d’une collation et/ou un apéritif (sponsorisés par OCamlPro).

Le premier meetup devrait se tenir fin septembre / début octobre. La date exacte et le programme seront communiqués sous peu. N’hésitez pas à vous inscrire dès maintenant dans le groupe pour ne manquer aucune information !

Les meetups se dérouleront à l’ENSEEIHT (2 Rue Charles Camichel, 31000 Toulouse), que nous remercions chaleureusement pour la mise à disposition de ses locaux.

Nous projetons d’ores et déjà d’organiser ces événements approximativement tous les deux mois. N’hésitez pas à venir présenter un sujet qui vous tient à coeur !

Lennart Augustsson has recently developed a Haskell library called Orthotope for dealing with multidimensional arrays. It can reflect shape and dimension information in types. You can also watch a video presentation about Orthotope.

There is likely no way to translate this to OCaml without significant type system extensions, but some of the concepts and ideas might inspire similar work.

I’m pleased to announce an initial release of ocaml-eris - an OCaml implementation of the Encoding for Robust Immutable Storage (ERIS): https://codeberg.org/eris/ocaml-eris/releases/tag/v1.0.0 (also available on OPAM).

ERIS defines an encoding of arbitrary content into a set of uniformly sized, encrypted and content-addressed blocks as well as a short identifier that can be encoded as an URN. The content can be reassembled from the blocks only with this identifier. ERIS allows a form of content-addressing that is optimized for transport over networks and allows content to be made available robustly.

ERIS is application and transport agnostic. A very similar encoding (ECRS) is used in GNUNet for file-sharing. Applications include transporting small pieces of RDF data or distributing Guix substitutes. Possible transports include HTTP, IPFS, CoAP and Sneakernets.

ERIS is formally specified and implementations for other language exist (and are being developed).

The OCaml ERIS implementation allows:

• Streaming encoding: Allows large content to be encoded while only keeping a minimal amount in memory.
• Random-access decoding: Decode small pieces of large content while de-referencing a minimal amount of blocks.
• Cross-platform support: See section below.

Note: ocamverse has now moved to [ocamlverse.net](ocamlverse.net).

Yes, OCaml decouples compilation of modules from each other. I collected some thoughts on that here: https://dev.to/yawaramin/ocaml-interface-files-hero-or-menace-2cib

Here are links from many OCaml blogs aggregated at the ocaml.org blog.

• Tarides Goes on Holiday!