OCaml Weekly News

I've just released ocaml-wayland, a pure OCaml Wayland implementation. You can get it with:

opam install wayland

Wayland is a communications system intended for use between processes on a single computer. It is mainly used by graphical applications (clients) to talk to display servers, but nothing about it is specific to graphics and it could be used for other things.

A Wayland protocol is defined by writing a schema file. Typed bindings can then be created automatically from that for various languages. Wayland's main interesting feature is that you can pass file descriptors as message arguments. For example, to send a frame of video you can get a file descriptor to some shared memory, draw the image to it, and then pass the FD to the server for rendering, with no need to copy the data.

The ocaml-wayland library can be used to write applications, display servers, or proxies. The example in the repository opens a window showing some scrolling squares. Clicking reverses the direction and pressing keys changes the colours.

I used the library to write wayland-virtwl-proxy, which allows applications running in VMs to open windows directly on the host desktop, as described in my recent blog post "Qubes-lite with KVM and Wayland".

Note that, unlike the older X11 protocol, Wayland doesn't provide any graphics primitives (such as drawing rectangles or text). Instead, applications render the window contents however they please and then simply share the buffer with the compositor. So if you want to write a normal application using it, you'll need to find or write a separate GUI toolkit too.

I have just released v2.1.0 of reparse to opam. Below are the CHANGES for this release. CHANGES:

This release has backwards incompatible changes.

• Infix functions are now available (opened by default) in Parser module itself.
• Add support for let operators - let+ , let* , and+ and and* .
• bind and map function are now labelled following base library dependency convention.
• Items in all_unit are now unit t rather than _ t following monad combinator convention in base library dependency.
• pure is now deprecated. Use return instead. This is to stay consistent with monad conventions in base library dependency.
• >|= is deprecated. Use >>| instead. This is to stay consistent with monad conventions in base library dependency.
• Removed map4 function.
• Add support for ppx_let .
• Deprecate Parser module. Use Reparse instead.

I'm proud to share with you the editor I've been working on theses last weeks, which is also open source!

The editor is available here: App Store link And the source code here: GitHub repository

A Pull Request just got merged, it is now part of the "Mobile" section on the Install page on the OCaml website.

Feel free to give your feedback, and/or contribute to the project on GitHub to help us to make a better tool!

I have dream, a day where this kind of app will be written in OCaml

I've done some experimental Cocoa bindings, and the basics are working, but the scope of the project is too large for a single person effort. Here's an example basic app: https://github.com/dboris/ocaml-cocoa/blob/master/examples/count_clicks.ml

Would be interested to contribute to a project with a similar goal, if someone has a better idea how to approach this.

Jeffrey Scofield has built some iOS apps with OCaml, so it's certainly possible: https://psellos.com/ocaml/compile-to-iphone.html

Yes, this app can be used offline!

It works with a toplevel built with js_of_ocaml, stored in the app, and everything runs on the device (You can browse on GitHub the OCaml/JavaScript/ folder which contains the toplevel itself). So as everything is already built-in, no internet connection is required.

I will clarify it on the App Store page, because even if it was evident for me, I notice it is not for everyone.

Last thing, I'm myself in CPGE (MPSI to be exact), and that's the reason why I started working on this app on my free time.

• how is automated the build and the upload of the app on the App Store? If a new OCaml version comes every couple of months, how much time would it require to rebuild and upgrade the app and publish/update it on the App Store?

• I build the app manually, and upload the file to the App Store. So if a new version of OCaml is released, I need to rebuild the top level with Js_of_ocaml, and build a new version of the app that I upload.

• Can users save (export) and import .ml files? If so, advertise this feature too! Can users write in more than one file at a time (like it's possible for BetterOCaml.ml in a single browser tab!)

• Users can open and save their .ml files, and even open them from the file explorer (double click on a .ml file will open it in the app), it's like a real code editor. For now only one file can be opened at time, but I plan to make a way to open multiple files (still thinking about it…)

• I guess I know the answer but… the technology you chose to build the app is limited to Apple-products only, and it's not a cross-platform technology like Flutter.dev or others recent technologies based on HTML/CSS/Javascript? If it is, how hard do you think it would be for you to also publish your app on Google Play store, and F-Droid.org ? The only app on Google Play is 10 year-old, for OCaml 3.12! https://play.google.com/store/apps/details?id=fr.vernoux.ocaml, it would be so great to publish a more recent and modern alternative!

• Of course I wrote the app with pure Swift (except the top level which is built with JS), but an Android version of the app can be written without problem (it's just about the user interface), and then published to the Google Play Store and whatever other store for Android phones.

As holidays are starting now in France, I will consider improving the app with feedbacks I got those last days, publish an update to the App Store, and start working on an Android version.

Please join us this coming Tuesday, April 13 at 7pm Central for OCaml Café. Zoom info is at https://hfpug.org/event/ocaml-cafe-3/

OCaml Café offers a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions.

Whether you’re still trying to make sense of currying or can spot non-tail-recursive code from across the room, we hope that you’ll join us with your questions about OCaml, or just to hang out with the OCaml community.

We released directories 0.3 recently. In this release, we dropped the Windows dependency on ctypes-foreign and use ctypes.stubs instead. See #10

This allowed us to clean the code and to remove some dirty hacks.

Welcome to the March 2021 Multicore OCaml monthly report! The following update and the previous ones have been compiled by me, @kayceesrk and @shakthimaan. We remain broadly on track to integrate the last of the multicore prerequisites into the next (4.13) release, and to propose domains-only parallelism for OCaml 5.0.

Sorry if this has been answered elsewhere – am I reading this correctly that effects aren’t intended for OCaml 5? If not, are there plans to merge effect handlers into mainline OCaml at some later stage, or is it going to be kept separate?

Just to be clear, effects are not slated for any official release of OCaml yet. The focus is on making sure that OCaml 5.0 is a really solid release with domains-only parallelism, and then to look into subsequent changes required for concurrency. There are some considerations about how precisely effects should work when they materialise in a mainline OCaml release:

• semantics: how will the introduction of effect handlers complicate (or improve!) reasoning about OCaml programs? @fpottier and Paulo Emílio de Vilhena have a paper on "separation logic for effect handlers" at POPL 2021 that is a good starting point to read from.
• performance: on the other side, we want to make sure that effect handlers do not introduce a runtime overhead to sequential OCaml code. Our paper on "retrofitting effect handlers onto OCaml" addresses this, with a particular restriction on making sure handlers are one-shot only (a position conveniently reinforced by @fpottier's paper above, as it also makes program reasoning much easier).
• type safety: our current implementation of effects is untyped, which doesn't fit that well into the spirit of ML. There is active research ongoing into developing a theory of typed effects lead by @lpw25, and you can see a tech talk about this.
• portability: OCaml is an extremely portable language, we want to make sure we can maintain clean compilation to existing targets (such as js_of_ocaml) and new ones (such as webassembly). @kayceesrk is active in the wasm working groups on this topic, and we're using MirageOS (which has compiler forks for esp32 embedded systems) to experiment with overheads using unikernels.
• ergonomics: and last but not least, the hardest one to answer: once we develop a workable model for typed effects in OCaml, does it work at scale on large codebases and also for writing incremental code that can be locally reasoned about? The only answer to this is to build prototypes of a significant size, which is something we're working on at OCaml Labs as part of efforts like our multicore IO stack. I don't talk about this much at the moment as we regularly thrown prototypes away, but we're converging on some stability in recent months.

To risk an analogy, imagine that we're flying from Cambridge to Fiji for a nice post-pandemic vacation. To get to our end goal, we have to fly via a few intermediate cities (say, London and Sydney). We need to be very careful not to screw up our landing into Sydney because we're so excited about eventually getting to Fiji – if we do that, there is no glorious holiday for us! And you know what? Sydney's not so bad a place to hang out and adjust to jetlag while we carefully plan the flight path to Fiji.

We could really use the community's help with OCaml 5.0, as it's going to be a major release. Rest assured that we're thinking (and working hard) on how concurrency should also show up in OCaml, but it won't happen until we get OCaml 5.0 out of the door. Core OCaml development is all about careful, iterative progress to avoid the risk of losing the properties that make OCaml so reliable for all the downstream projects that depend on us.

Having said all that, I can't wait to get to get to Fiji either. It's going to be an awesome vacation when we finally arrive.

(tl;dr)

The ML family workshop is back, and will be held virtually along with ICFP 2021. The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. The PC has a broad expertise and submissions are 3 pages long: when in doubt, just submit!

(long version)

We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021.

The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas.

A common problem that I personally had when developing async code in OCaml is that both Lwt and Async leads to useless stack traces. When using lwt_ppx that is handled by the ppx, but the same is not possible with let*, let.await or >>=.

If you want to solve that, you can use ppx_let_locs, it will detect your calls and when there is a replacement function available that would allow stack traces to be enhanced it will enhance that by default for you.

For me reading the cmi is enough, so I implemented it on ocaml-migrate-types, it can do 411 -> 412 types, will implement 410 -> 411, which is probably painful because of the Uid

https://github.com/EduardoRFS/ocaml-migrate-types/blob/main/src/migrate_411_412.ml