View on GitHub

OCamlverse

Documenting everything about OCaml

Page Contents

Edit

Future of OCaml

Some interesting news/developments coming up in OCaml’s future:

Ongoing

Concurrency and Parallelism with OCaml

OCaml 5.0 has integrated Multicore OCaml, which provides building blocks for concurrent and parallel programming. It includes algebraic effect handlers that can express computational effects, including resumable exceptions, delimited continuations, and asynchronous computations. Additionally, domains, abstractions of native threads, can run simultaneously on shared-memory multiprocessor systems.

The OCaml community has taken advantage of these new features by developing several libraries, and the ecosystem has evolved to gain full potential from today’s hardware. For more information, visit the Concurrency, Parallelism, and Distributed Systems page.

Medium-Term Plans

Flambda2

Flambda is an optimization framework introduced in OCaml 4.03. It allows for conveniently inlining small code snippets, resulting in a faster binary. However, the trade-off is a longer compilation time. It should be noted that Flambda is currently an opt-in feature of the compiler.

Flambda2 is the successor to Flambda and is currently being developed at https://github.com/ocaml-flambda/flambda-backend.

WebAssembly

WebAssembly, or Wasm, is a portable binary instruction format that can be used with any programming language. It runs in a secure environment embedded within web browsers.

Porting OCaml to Wasm has excellent potential. While we already have OCaml to JavaScript compilers, the compiled code is more or less inefficient as JavaScript is not designed as a low-level target language. Wasm will fill the gap and lead to high-performance client-side web applications written in OCaml.

Long-Term Plans

Modular Implicits

Haskell’s type classes, Scala’s implicits, and Rust’s traits are solutions to the expression problem, a well-known problem of programming language design formulated by Philip Wadler in 1998. Modular implicits were introduced as OCaml’s solution to the expression problem in 2014.

As clarified in the original paper on modular implicits, adding type classes to OCaml is difficult due to its adherence to type abstraction. In short, you can have functors or type classes, but not both, and OCaml already has functors. While the community eagerly awaits this solution, its implementation, unfortunately, appears to be years away.

Typed Algebraic Effects

Algebraic effects and handlers are a way to model various computational effects in a composable manner. They can express assignments, I/O operations, exceptions, iterators, asynchronous computations, non-deterministic computations, etc.

The experimental support for algebraic effects was introduced in OCaml 5.0. However, the type system does not provide dedicated functionalities to track effects. In other words, algebraic effects in OCaml 5.0 are untyped. It introduces various problems, and it would be better to have algebraic effects typed and handled by the type system instead. By extending OCaml’s type system with algebraic effects, it would become more similar to Haskell’s but without the need for monads for effects.

Notable Ideas

Certifiable OCaml Type Inference

OCaml’s type checker is complex and fragile, as noted in ocaml/typing/TODO.md in the compiler codebase. While refactoring the type checker for lower maintenance costs is a priority, it is tough for less experienced developers to participate. The type system has many features, so the underlying algorithm is hard to comprehend. Additionally, the implementation could be better structured.

The Certifiable OCaml Type Inference (COCTI) project aims to develop the foundation for a “robust, modular, and verifiable” type system implementation for OCaml. In addition to the cleanup and refactoring of the existing code base, COCTI develops a compiler backend targeting Gallina, Coq’s programming language, and proofs of soundness of the type system, among others.

Most code on COCTI is available at https://github.com/COCTI/ocaml.

Modes

OCaml’s generational garbage collector efficiently handles short-lived small values OCaml programs often produce. While it works well, one can improve the performance even more if such ephemeral values are allocated to a stack, like local variables in C.

However, we must ensure that stack-allocated values are not referenced from heap-allocated long-lived values to prevent use-after-free bugs. A similar problem is also in values shared between multiple threads. Rust’s type system has the concept of lifetime and ownership to manage such values safely at the cost of complexity.

Modes provide a proper subset of Rust’s lifetime and ownership separate from the type system. A prototype of modes-enabled OCaml is being developed at https://github.com/ocaml-flambda/ocaml-jst.

Unboxed Types

OCaml uses a uniform memory layout of values to implement parametric polymorphism without duplicating mostly identical code snippets for each type, as C++’s templates do under the hood. The disadvantage of a uniform memory layout is the overhead of memory space and execution time.

Unboxed types do not follow the uniform memory layout to improve performance. With unboxed types, programmers can opt-in to unboxed types when desired at the cost of duplicating code for each unboxed type. Work on unboxed types is ongoing at https://github.com/ocaml-flambda/ocaml-jst.