OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of October 18 to 25, 2022.

Table of Contents

tablecloth-native 0.0.8 released

Paul Biggar announced

We’ve released version 0.0.8 of Tablecloth, an ergonomic, cross-platform standard library to allow you share code between OCaml and Rescript. This version has dozens of new functions, which you can see in the Changelog.

You can install it:

  • in Rescript: via npm as tablecloth-rescript
  • in OCaml: via opam as tablecloth-native

From the announcement:

This is the last release of Tablecloth in this format. As Rescript and OCaml have diverged, Tablecloth’s old purpose (a library to allow you to share code between ReasonML and OCaml) no longer makes sense (and in fact we had struggled to get much value out of sharing code between the two).

What we actually found valuable about Tablecloth was being able to use the same function names in our multiple codebases.

As such, we’ve refocused Tablecloth to be a simple shim over existing standard libraries, allowing developers who use multiple languages to have a consistent set of standard library functions, while being idiomatic to language they’re in (eg pipe-first vs pipe-last, camelCase vs snake_case). The next release is planned to support OCaml, Rescript, and F#.

ocaml-lsp-server 1.14.0

Rudi Grinberg announced

On behalf of the ocamllsp team, I’m pleased to announce version 1.14.0. This release contains a new code action to help you inline definitions thanks to @jfeser. We look forward to your feedback.

Full change log:

Features

  • Code action for inlining let bindings within a module or expression. (#847)
  • Tag “unused code” and “deprecated” warnings, allowing clients to better display them. (#848)
  • Refresh merlin configuration after every dune build in watch mode (#853)

Fixes

  • Respect showDocument capabilities. Do not offer commands or code actions that rely on this request without client support. (#836)
  • Fix signatureHelp on .mll files: avoid “Document.dune” exceptions

What are pros and cons of Eliom web framework?

Volodymyr Melnyk asked

I’m interested in pros and cons of Eliom web framework to understand if it is well suitable for my idea of corporate blogging/content marketing SaaS. What successful SaaS projects made with Eliom do you know? Do you know any issues related to Eliom (or why many people prefer, for example, Dream)? Also I’m interested if there are any popular iOS apps made with Eliom?

Vincent Balat replied

There is a huge app written with Eliom: The Be Sport social network. It was written by a team of 2 to 15 developers over the past 7 years (including Jerôme Vouillon and myself, who are the creators of Ocsigen). You can have a look here: https://www.besport.com/news and download the mobile apps on Google Play store or Apple app store.

Be Sport is 100% written in OCaml with Ocsigen, as multi-tier and multi-platform Eliom app. There is only one code base for the server part and the Web, Android and iOS clients. The mobile apps are running in in webviews, using cordova (or may be soon capacitor). Pages are generated on server side (for example for indexing by search engines, or if it is the first page you load) or on the client (in client apps, or if you change page in the Web app). This is the most distinguishing feature of Eliom w.r.t. any other Web framework (in any programming language).

Another advantage of multi-tier programming is that Web APIs are generated automatically by Eliom. More generally communication between server and client are transparent: as you have only one program, you can call server side OCaml functions from your client side OCaml program. Communication from server to clients (notifications) is also handle by Eliom. Of course you can define your own APIs if you need to interact with third party apps.

When you master them, these features save a lot of time and are probably what made possible to implement a very complete Facebook-like social network with such a small team. Of course if you don’t need all this, you can use Eliom for more traditional Web programming and it be very similar to what you can do with Dream.

Server parts of your app are compiled to OCaml module, loaded dynamically into Ocsigen Server (which is now using cohttp as HTTP lib) through its configuration file. There is currently no way to write standalone apps without this dynlink, but it is in our todo list.

Clients parts are compiled into Javascript with js_of_ocaml.

Other features of Ocsigen:

As Ocsigen innovates in many fields, you have some learning to do to become fully operational (lwt, reactive programming, multi-tier programming, html typing with polymorphic variants and phantom types, etc.). Everything is summarized on the first chapter of the programming manual.

Ocsigen is now mature. It can work without a lot of maintenance. However the project is currently not funded (no developer is currently paid to work on Ocsigen).

Do not hesitate to contact me if you need to build a team for your project. I may have some names.

Volodymyr Melnyk then asked and Vincent Balat replied

Thank your for such a detailed response. I have few questions about Eliom:

  1. Does it support SOA/microservice architectures or only monoliths?
  2. Does it support “backends for frontents” approach?

We did not work on microservices which means that if you want to implement some microservices, you can, but I guess it will be very similar to what you can do with other frameworks. The BFF patterns does not make a lot of sense in our vision, as you have only one frontend and build the frontend and backend together as a single app. Our multitier approach removes most the problems of multi-frontend apps. When programming with Eliom, you don’t have separate teams for each frontend and backend. One developer is responsible for its own feature from the db to the interface and for all patforms, which reduces a lot the need of communication between teams, and the risk of API problems. However if you want several backends, for example to interact with external apps, of course you can do that. Eliom does reduce the possibilities w.r.t. more traditional Web programming.

10332d49eb6ebf67e3ef84047bed384ae7bc248c_2_1380x696.jpeg

dune 3.5.0

Etienne Millon announced

I’d like to announce the release of dune 3.5.0 on opam. This release is packed with fixes and new features, that are described below with a description of what this means for project maintainers.

dune executable

This lists features of the “dune” executable itself. Upgrading dune will bring in these changes. We consider these changes safe, but it is difficult to define what a breaking change is for a command-line tool (for example, some error messages change). It is important to note that just upgrading the dune executable is not supposed to change how dune interprets existing projects. If just upgrading dune breaks compilation, it is a bug in dune, please report it!

  • Added
    • Allow dune describe workspace to accept directories as arguments. The provided directories restrict the worskpace description to those directories. (#6107, fixes #3893, @esope)
    • Add a terminal persistence mode that attempts to clear the terminal history. It is enabled by setting terminal persistence to clear-on-rebuild-and-flush-history (#6065, @rgrinberg)
  • Fixed
    • Fix build-info version when used with flambda (#6089, fixes #6075, @jberdine)
    • Fix compilation of Dune under esy on Windows (#6109, fixes #6098, @nojb)
    • Improve error message when parsing several licenses in (license) (#6114, fixes #6103, @emillon)
    • Handle CSI n K code in ANSI escape codes from commands. (#6214, fixes #5528, @emillon)
    • Do not ignore rules marked (promote (until-clean)) when --ignore-promoted-rules (or -p) is passed. (#6010, fixes #4401, @emillon)
  • Changed
    • dune install: copy files in an atomic way (#6150, @emillon)
    • update vendored copy of cmdliner to 1.1.1. This improves the built-in documentation for command groups such as dune ocaml. (#6038, @emillon, #6169, @shonfeder)
    • Extend dune describe to include the root path of the workspace and the relative path to the build directory. (#6136, @reubenrowe)

macOS support

This is technically a subset of above section. For M1 mac users, dune 3.5.0 is the first version which will correctly support dune-build-info.

  • Added
    • on macOS, sign executables produced by artifact substitution (#6137, #6231, fixes #5650, fixes #6226, @emillon)
    • Enable file watching on MacOS SDK < 10.13. (#6218, @rgrinberg)
  • Fixed
    • macOS: Handle unknown fsevents without crashing (#6217, @rgrinberg)

(lang dune 3.5)

This lists changes if you opt into the new (lang dune 3.5) version in your dune-project file. For this too, these are changes that we consider safe, but they can require changes to your dune files. For example, sandboxing is enabled in more places, which means that you might have to be more precise in expressing your dependencies. Please reach out on the issue tracker if you have trouble fixing your dune file or if something does not seem to be possible anymore.

  • Added
    • Add a runtime_deps field in the cinaps stanza to specify runtime dependencies for running the cinaps preprocessing action (#6175, @rgrinberg)
    • Allow rules producing directory targets to be not sandboxed (#6056, @rgrinberg)
    • Introduce a dirs field in the install stanza to install entire directories (#5097, fixes #5059, @rgrinberg)
    • Add an (include <file>) term to the include_dirs field for adding directories to the include paths sourced from a file. (#6058, fixes #3993, @gridbugs)
    • Support (extra_objects ...) field in (executable ...) and (library ...) stanzas (#6084, fixes #4129, @gridbugs)
    • Allow rules producing directory targets to create symlinks (#6077, fixes #5945, @rgrinberg)
    • Added an (aliases …) field to the (rules …) stanza which allows the specification of multiple aliases per rule (#6194, @Alizter)
    • Allow include statement in install stanza (#6139, fixes #256, @gridbugs)
    • Add a new experimental feature mode_specific_stubs that allows the specification of different flags and sources for foreign stubs depending on the build mode (#5649, @voodoos)
  • Changed
    • Sandbox running cinaps actions starting from cinaps 1.1 (#6176, @rgrinberg)
    • Cinaps actions are now sandboxed by default (#6062, @rgrinberg)
    • Menhir rules are now sandboxed by default (#6076, @rgrinberg)
    • Inline tests are now sandboxed by default (#6079, @rgrinberg)
  • Fixed
    • Shadow alias module Foo__ when building a library Foo (#6126, @rgrinberg)
    • Disallow generating targets in sub direcories in inferred rules. The check to forbid this was accidentally done only for manually specified targets (#6031, @rgrinberg)
    • odoc rules now about ODOC_SYNTAX and will rerun accordingly (#6010, fixes #1117, @emillon)

Coq support

These changes, associated with (lang dune 3.5), are specific to coq.

  • Added
    • Add %{coq:...} macro for accessing data about the configuration about Coq. For instance %{coq:version} (#6049, @Alizter)
    • Starting with Coq build language 0.6, theories can be built without importing Coq’s standard library by including (stdlib no). (#6165 #6164, fixes #6163, @ejgallego @Alizter @LasseBlaauwbroek)
  • Changed
    • Dune no longer considers .aux files as targets during Coq compilation. This means that .aux files are no longer cached. (#6024, fixes #6004, @alizter)
    • The test suite for Coq now requires Coq >= 8.16 due to changes in the plugin loading mechanism upstream (which now uses Findlib).
    • The (coq.theory ...) stanza will now ensure that for each declared (plugin ...), the META file for it is built before calling coqdep. This enables the use of the new Findlib-based loading method in Coq 8.16; however as of Coq 8.16.0, Coq itself has some bugs preventing this to work yet. (#6167 , workarounds #5767, @ejgallego)

Killer use-cases (tools, libraries, domains, etc) for OCaml

Bozhidar Batsov asked

I wanted to ask all of you to share your thoughts on what are the killer use-cases for OCaml today (think along the lines of Rails for Ruby, systems programming for Rust, data science for Python, etc). Basically I want us to discuss the type of problems for which OCaml is a great fit and the tools (e.g. libraries, frameworks, etc) that go hand-in-hand with the respective problem spaces. E.g. one can say that OCaml is a great option for building parsers because of Menhir and so on.

In a way the topic is similar to the recent topic about favorite libraries (see https://discuss.ocaml.org/t/top-5-favorite-ocaml-libraries/10626/17), but I’ve noticed most people there mentioned just basic libraries, which don’t really help to understand how are they actually using OCaml and what do they consider its strongest areas.

Eric Taucher replied

A few Proof Assistants are written with OCaml

Nicolas Ojeda Bar also replied

Symbolic computation (compilers, interpreters, DSLs, etc) is OCaml’s “traditional” bread and butter, but at LexiFi we use OCaml for everything from web frontends (via js_of_ocaml), to server backend (databases, web servers), native UIs, high performance numeric code, etc; in our experience OCaml is an excellent choice for each one of these. I shudder when I think about maintaining (not so much implementing) this code in more “popular” languages.

Olle Härstedt also replied

To add to that, Facebook uses OCaml for Hacklang type-checking, Flow type-checking, and their pfff analyzer.

Oh, pfff is discontinued, I see now. The other two should still be used. And apparently they made a Python analyzer too.

https://github.com/orgs/facebook/repositories?q=&type=all&language=ocaml&sort=

Artem Pianykh also replied

Meta’s Infer is too implemented in OCaml https://fbinfer.com/ But this is still the same symbolic computation area.

From my experience, OCaml is a good general purpose language. It has a reputation of being esoteric, but in fact it’s much more straightforward than, say, Haskell. However, the ecosystem is historically much more tuned to compilers, static analysis tools, etc.

Although, there are libraries for web and whatnot, I feel when it comes to running stuff in prod it’s less mature than what you’d find e.g. on the JVM.

Kay-Uwe Kirstein also replied

In the engineering/data science domain I use OCaml to deal with unstructered (measurement) data, e.g., parsing logfiles, import/export from device specific databases, and controlling of test equipment. The range is from small script-like tools to convert data to complete desktop applications to run production tests in an assembly line (incl. GUI, controlling test equipment, and database storage).

OCaml’s strength here is the support for robust tools that rarely show undefined behavior in case of unexpected input data. Applications usually run everyday without errors/crashes. Also, extending and refactoring for changed or extended requirements hardly breaks existing funcionality. This is probably due to the strong type system and functional paradigm, and the high quality of compiler/build tools and libraries.

OCaml’s weak points are the perception as an exotic programming language which makes it harder to gain acceptance in other software teams and the development experience on Windows. The main “competitors” in the described fields are Python and C#/.NET (I am working in a Windows-centric company).

According to the described use cases, the following libs are on my top list:

Dennis Dang asked and Kay-Uwe Kirstein replied

That’s a huge range of applications with OCaml!

I don’t ever go work related to hardware. How do you go actually “[control] test equipment” with OCaml? Is there a assembly/c api that you use and wrap OCaml over?

Yes, usually the test equipment supplier provides a C-api for their instruments. With OCaml‘s C-api it is easy to write bindings for that, sometimes with the help of the ctypes library. There is also a communication/driver standard called VISA that can be used for different instruments (and therefore can reuse generated OCaml bindings for it)

Snóke, a good (?) old game

sanette announced

I’m proud to announce a super original new game entirely written in ocaml, one that you can not play in your browser (this is to save energy, of course ;) ): Snóke! The ó is for Ocaml, or Original, or whatever.

https://github.com/sanette/snoke

Yes, it is yet another variant of the classic 1976 snake video game, but there is a new idea (well, at least I couldn’t find it elsewhere, please don’t disprove me): the goal is not to eat as many apples as possible, but just the exact amount to cover a “shed skin” (or ghost snake, if you prefer, this is the grey snake in the screenshot).

You can already have… well maybe a few minutes of fun with it, but of course contributors are welcome to make it even better.

459406484b8faba4b1c3bff15c1e431c11f6260c_2_1146x1000.jpeg

Vidéo: https://youtu.be/h1MC9-xDKFA

Interesting: Running WebAssembly in OCaml with Wasmer

Christian Lindig said

Running WebAssembly in OCaml with Wasmer

I found the article above and think it is exciting: how OCaml code can call WebAssembly code which in turn could have been created from many languages. I assume the authors are here - so maybe they can comment on this?

OCaml Community Code of Conduct

Sudha Parimala announced

Here’s our new draft of the proposed Code of Condcut for the OCaml community. The link in the original post is updated to reflect the latest version of the draft. Many thanks to everyone for the thoughtful suggestions. After taking into account the feedback we received here and in private, we’ve decided to go with the Coq Community Code of Conduct as our base text.

We’ve retained the section on strained situations from our previous draft. The text is due to @bobot, who wrote it for a previous iteration of the Code of Conduct text. We’d like to make it clear that this part of the text was not derived from contributor covenant. This section was written during the times of covid lockdowns and made a lot of sense to include, with many people having limited contact with the outside world. Thankfully we’re past the lockdown stages at most places, still we believe it’s useful for people to reach out to us in difficult situations even if there isn’t a clear code of conduct violation.

Scope

As mentioned in the document, the Code of Conduct is currently proposed to be enforced at:

  • OCaml github org
  • discuss.ocaml.org forum
  • caml@inria.fr mailing list
  • OCaml IRC

and other spaces managed by the OCaml development team and OCaml Software Foundation.

Next steps

Any comments and ideas regarding the text are appreciated. We kindly request everyone to keep the discussions relevant to the proposed text and OCaml community. If there are no strong objections, the Code of Conduct will be enforced in the spaces listed above. The admins and moderators of those spaces have kindly approved to the idea.

We’d very much appreciate more maintainers following suit and implementing the Code of Conduct for their projects. It’s completely up to the maintainers to decide to do so for their projects. The maintainers can also choose to list the contact details of the Code of Conduct committee, at the discretion of the committee members. We will come back with more details on this process soon.

Happy inclusive camling, @Khady, @mseri, @rjbou, @c-cube, @pitag, @sudha

multicodec, multibase, multihash and multihash-digestif

Patrick Ferris announced

Happy to announce the initial release of four somewhat related packages. They are all libraries falling under multiformats, which are

Self-describing values for Future-proofing. The Multiformats Project is a collection of protocols which aim to future-proof systems, today. They do this mainly by enhancing format values with self-description. This allows interoperability, protocol agility, and helps us avoid lock in.

Releases

  • Mutlicodec

    Multicodec is a fairly simple package providing OCaml values and types for the multicodec. This is an agreed upon mapping of integers to protocols.

  • Multibase

    Multibase provides self-identifying base encodings, so given a multibase-encoded string, this library can tell you what the base encoding was and if supported it will then decode the message. You can of course also encode messages too, with the currently supported encodings being Base32, Base58 and Base64.

  • Multihash and Multihash-digestif

    Multihash provides self-describing hash functions. The library multihash takes a hash implementation and provides multihashes. Multihash-digestif is multihash using digestif as an implementation.

    • Use Case

      One fun thing you can do is replace Irmin’s hash implementation with Multihash.

      let main () =
        let open Lwt.Syntax in
        let config = Irmin_mem.config () in
        let* repo = Store.Repo.v config in
        let* main = Store.main repo in
        let* () = Store.set_exn ~info main [ "a" ] "Hello World" in
        let* hash = Store.hash main [ "a" ] in
        match hash with
        | Some md ->
            Format.printf "%a%!" Multihash_digestif.pp md;
            Lwt.return_unit
        | None -> assert false
      
      let () = Lwt_main.run (main ())
      

      And this program prints

      ident(sha2-256) length(32) digest(4a 2b 43 6f 2b 5a 16 b0  1e 3c e5 28 5e 88 b1 99
                                        a9 a4 ae fd b1 e1 6a c8  31 c3 32 d4 92 c5 d1 57
                                        )
      

      See this gist for all of the details.

Furture Work

Two short term goals are:

  1. Release Content-addressed Identifiers (CID)
  2. Release multiaddr

Thanks for reading :))

Timmy, a time and calendar library

mefyl announced

Much of the work we do at Routine revolves around calendar features, and over time an internal library emerged to address some common needs in that regard. As we strive to open source most of our reusable code, I’m pleased to submit the current 0.14.2 version of Timmy for comments.

The philosophy and rationale for the library is explained at length in its root module documentation, so I will only sum up here that our design goals and possible differentiator are a high level interface, type safety, timezone safety, DST support and advanced calendar features.

We’d be happy to collect feedback on the current API and usefulness of the library before committing to a stable API.

Opam hacking afternoon for OCaml 5.0.0 on Friday 28

octachron announced

With the newly released beta for OCaml 5.0.0, I will be spending more time looking at updating opam packages to make them compatible with OCaml 5.0 in the coming month.

As an experiment, I am planning to have an open hacking session for opam packages on Friday afternoon starting at 16h00 Paris time. If people are interested to join me to do some live opam package fixing, you are very welcome.

Currently, I am planning to work with a manually updated synchronization note at: https://hackmd.io/@octachron/HkaQfvV4i .

Antonio Nuno Monteiro then said

We’ve been hard at work getting our nix-overlays package set ready for OCaml 5.0 too!

Feel free to look into this file for specific Git commits / branches and patches applied on top of many of the existing packages.

Our exclusion list for OCaml 5 has been getting smaller almost every day since a few months ago.

Other OCaml News

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 online.