OCaml Weekly News

We are looking into improving the “Overview/Description” page of a package. Since this is basically the “landing page” of the package, it needs to both look great and include the most relevant info. We want you to be able to estimate at a glance whether the package is one that you might want to use, and to find the most important landmarks (e.g. CHANGES.md, LICENSE.md, Documentation, package homepage) of the package easily.

Share your thoughts about it!

• What would be useful to see appearing on the page overview page?
• We’re also very interested in your favorite package overview pages from other languages. Please do share screenshots of package overview pages that you really like to use in this thread. We are compiling a moodboard in order to systematically analyze how to best arrange the content that we have and to be inspired on what looks great while being usable at the same time.

Your opinions matter and your feedback is used to improve our work.

Editor’s note: there were many replies, please follow the archive link above to read them.

I’m please to announce the first release of the prr library: prr.0.1.1.

Prr is a fork and a stripped-down version of the widely used JavaScript FFI library brr, which is originally built by @dbuenzli.

There are two major differences between brr and prr:

1. prr uses dune as its build system. This allows easier vendoring through dune’s vendoring support.
2. prr includes only non-browser specific components of brr, so that it could be safely used in JavaScript environments like those of Node.js and React Native projects, in addition to targeting web. (In fact this is our motivation to fork brr in the first place.)
   • prr’s README gives an overview of what is included and what is not.

No need to say that we are basically freeloading @dbuenzli and brr contributors’ efforts in building such a wonderful FFI library so special thanks to the contributors of brr.

We will be actively maintain compatibility between prr and brr and closely follow the developments of brr.

To install, simple run opam install prr, list prr as a dependency of your project, and open Prr. Code that previously depends on brr should work without modification if no access to browser specific APIs is used.

Comments and suggestions are mostly welcomed.

We are looking for motivated people to be members of the ICFP 2023 Artifact Evaluation Committee (AEC). Students, researchers and people from the industry or the free software community are all welcome. The artifact evaluation process aims to improve the quality and reproducibility of research artifacts for ICFP papers. In case you want to nominate someone else (students, colleagues, etc.), please send them the nomination form.

Nomination form: https://forms.gle/RDomoHLv39RnjBUC6

For more information, see the AEC webpage: https://icfp23.sigplan.org/track/icfp-2023-artifact-evaluation

The primary responsibility of committee members is to review the artifacts submitted corresponding to the already conditionally accepted papers in the main research track. In particular, run the associated tool or benchmark, check whether the results in the paper can be reproduced, and inspect the tool and the data.

We expect evaluation of one artifact to take about a full day. Each committee member will receive 2 to 3 artifacts to review.

All of the AEC work will be done remotely/online. The AEC will work in June, with the review work happening between June 5th and June 29th.

Come join us in improving the quality of research in our field!

Best, the Artifact Evaluation chairs: Jannis Limperg and Quentin Stiévenart

There is a second book on Owl: Architecture of Advanced Numerical Analysis Systems - Designing a Scientific Computing System using OCaml.

Free download in PDF and ePub formats!

>From the OCaml survey and several discuss threads, it seems clear that documentation is an important issue in OCaml, especially with PPXs. I’m pleased to announce two improvements on this side: the publication (last summer) of our new “Preprocessors and PPXs” guide on OCaml.org, and the vast enhancement of the ppxlib documentation (very recently).

The ocaml.org guide is targeted at newcomers who don’t know what a PPX is, nor how to use them.

The ppxlib’s documentation is targeted at PPX authors, as well as PPX users who want to know more about the advantages, and what’s under the hood, of ppxlib.

The improvements in the ppxlib’s documentation are:

• More content: many new sections and explanations were added.
• More discoverability: Instead of being spread in many API pages, the “general” documentation is gathered in .mld pages focused on a specific topic, such as “matching code”, “good practices”, etc. API pages are focused on the API itself, with links to the relevant sections of the manual.
• Thanks to odoc, I could also easily add many links from the manual to the API items.
• Many code snippets did not compile, due to programming typos or outdated API. Those were corrected and improved.
• The API landing page was very difficult to navigate. It is now more organized, with sections, and docstrings for every toplevel modules.

The manual can still be improved in many ways. There are many sections that could be added or improved. A global navigation bar would help a lot the navigation in the mld pages. I will also add soon a check that code snippets don’t go outdated, using mdx (on .mli first, but also on .mld as soon as the relevant mdx PR is finished and merged!).

Overall, writing documentation has been very smooth for me. I would encourage the community to contribute to the documentation effort: PRs for improvements of ppxlib’s docs are warmly welcome, and I’m sure that’s the case for many packages! It is really a killer feature to have all docs centralized on ocaml.org, and odoc is a great tool for writing both an API and a manual with interconnected links; Let’s make the best use of this!

Thanks a lot to @pitag and @professor.rose for the very valuable and comprehensive reviews, respectively on content and form, which highly improved the quality of the documents! Thanks also a lot to Tarides and Jane Street for sponsoring me to work on this task!

I’m reviving this topic because there is now a concrete proposal to change the Github Linguist color for OCaml from “neon green” 3be133 to “orange” ee6a1a. The person proposing the change wants to know whether “the OCaml community” agrees with the proposal and opened a poll:

https://github.com/ocaml/ocaml/discussions/12013

Please go there if you want to give your opinion on the proposed change.

Note: “github linguist” is used to detect which languages are used in git repositories, with summaries shown automically and a color code to display the proportions. This is used on both Github and Gitlab. See for example the “Languages” section at the end of the right column on the webpage https://github.com/ocaml/ocaml.

Note: past discussions in the present thread are irritated by a limitation that one is not allowed to pick a color close to an existing language’s color. My understanding is that this limitation has since been removed, so any choice of color for OCaml would do.

@glennsl you previously proposed a slightly different shade of orange, ef7a08 rather than ee6a1a. If you happen to have a strong opinion on one rather than the other, now would be a good way to voice it on the poll/discussion thread.

The recording of Paul’s talk is now available on our website at https://hfpug.org. He discusses rewriting the OCaml codebase at about 30 minutes in. His basic argument was that the F# ecosystem was much stronger – libraries, tooling, etc. What was more interesting to me were some of his criticisms of Rust (which is also the subject of one of his blog posts).

I recently held a talk on the work:

k-CAS for sweat-free concurrent programming

See the video and slides, including full speaker’s notes.

The next OUPS meetup will take place on Thursday, 16th of March 2023. It will start at 7pm at the 4 place Jussieu, 75005 Paris.

:warning: :trumpet: It will be in the in the Astier amphitheater in the Esclangon building. :trumpet: :warning:

Please, register on meetup as soon as possible to let us know how many pizza we should order.

For more details, you may check the OUPS’ website .

This month will feature the following talks :

Deux moteurs de recherche pour l’ecosystème OCaml – Arthur Wendling

Sherlocode et Sherlodoc sont deux petits outils pour explorer les nombreux projets publiés sur opam. Le premier permet de `grep` en temps réel leur code source, tandis que le second facilite la recherche dans leur documentation (à la Hoogle). Durant la présentation, on verra que ces outils existent pour satisfaire deux envies : répondre à des questions tordues sur l’usage d’OCaml, mais aussi apprendre à coder ce type de moteur de recherche. On expliquera donc comment les recherches par regex et par type ont été implémentées, grâce à des astuces élégantes empruntées à la littérature… et des hacks douteux qu’il vaudrait mieux ne pas ébruiter.

Creusot a prophetic verifier for Rust – Xavier Denis

Rust is a fairly recent programming language for system programming, bringing static guarantees of memory safety through a strong ownership policy. This feature opens promising advances for deductive verification, which aims at proving the conformity of Rust code with respect to a specification of its intended behavior. We present Creusot, a tool for the formal specification and deductive verification of Rust. Creusot’s specification language features a notion of prophecies to reason about memory mutation. Rust provides advanced abstraction features based on a notion of traits, extensively used in the standard library and in user code. The support for traits is at the heart of Creusot’s approach of verification and specification of programs

The dune team is pleased to announce the release of Dune 3.7.0.

As in the previous announce, here is a changelog split in several parts: changes to the dune executable itself (new commands or options, etc) and changes to the dune language. Most of the changes to the latter are only enabled when you opt-in to the new version by specifying (lang dune 3.7) in the corresponding dune-project file. In other words, it should always be safe to upgrade the dune package.