HaskellR: letting Haskell call R and R call Haskell across one FFI

The point is calling across the boundary in both directions

The HaskellR project provides an environment for efficiently processing data using Haskell or R code, interchangeably. The key sentence is the next one: HaskellR allows Haskell functions to seamlessly call R functions and vice versa.

That two-way property is what separates it from a one sided binding. A library that only exposes R to Haskell leaves the R programmer stranded, because the natural place to write a piece of R code is still R, and having to call out to a Haskell process for a helper function is a different kind of cost from a function call. Letting the R side call back into Haskell means a numerical routine can call a Haskell function that, say, owns the domain types, and neither side has to be rewritten in the other's idiom.

The payoff the documentation names is breadth rather than novelty. It gives the Haskell programmer the full breadth of existing R libraries and extensions for numerical computation, statistical analysis and machine learning. In other words, HaskellR is the answer to a specific and common situation: the tooling you need is written in R, the system you are building is in Haskell, and rewriting the R part is not on the table.

The project topics are ffi, haskell, interoperability and r, which is an accurate summary of the mechanism. The project is hosted by Tweag, the website is tweag.github.io/HaskellR, and there is a Google Groups mailing list for discussion.

The tree holds an R implementation and the Haskell side

The repository layout shows the two halves of the project and the machinery around them.

There is a directory named H/ and another named IHaskell/, and a third named inline-r/, which together suggest the split between the Haskell library, the inline R interpreter layer and the R sources that are embedded into the build. There is a pkg/ directory, which in a project like this holds the R packages that are made available to the runtime, and an etc/ directory that carries package metadata rather than code.

Alongside those sit docs/ for the documentation sources, and an examples/ directory with a HaskellR-examples.cabal file, its own LICENSE, and example programs: an fft/ directory, a fib/ directory for the Fibonacci example, and two nls/ directories, nls/ and nls2/, for the nonlinear least squares examples. The choice of examples is informative on its own. An FFT and a nonlinear least squares solver are the two problems where you would expect a numerical team to reach for R in the first place, and they exercise the boundary in both directions rather than demoing a single call.

There is also a .github/ directory with the continuous integration workflow, and the README links to the website for all documentation rather than repeating it, which is a reasonable division for a project of this size.

Stack builds it, and Nix replaces Docker

The project uses Stack, and the README points at the Stack documentation for how to build, run the tests and benchmarks, and build the API documentation. All of that happens with one command:

$ stack build --test --haddock --bench

The optional twist is the --nix flag, which can be passed to all the commands if you have the Nix package manager installed. What Nix does here is populate a local build environment including all the necessary system dependencies without touching your global filesystem, and the README describes it as a cross-platform alternative to Docker.

That is a meaningful choice for this particular project, because a Haskell and R hybrid needs both a Haskell toolchain and a working R installation with the right libraries, and the failure mode of getting that wrong is subtle. A local environment that Nix assembles from a pinned description is reproducible in a way that a hand assembled container image is not, and the fact that the flag exists at all means the project has users on more than one platform.

The repository carries the pinning to match. There are stack-lts-21.yaml, stack-lts-22.yaml and stack-lts-24.yaml, each with a lock file, alongside a stack.yaml and its lock, and the Nix side has shell-lts-21.nix, shell-lts-22.nix, shell-lts-24.nix, a plain shell.nix and nixpkgs.nix. Three language snapshots, each with both a Stack and a Nix spelling, is what a project that must build against several R and GHC combinations looks like in practice.

The licence is a custom one with a clear provenance

The licence section is short but specific. The copyright lines are Amgen, Inc. for 2013 to 2015 and Tweag I/O Limited for 2015 to 2022, all rights reserved. The statement is that HaskellR is free software and may be redistributed under the terms specified in the LICENSE file.

The licence field on the repository itself is recorded as a custom licence that GitHub cannot classify, so the file in the repository is the text that governs, and it is worth reading before you vendor it. The two company copyright lines also tell you something about the project's history: it began inside a large pharmaceutical research group and moved to a consultancy with a strong Haskell practice, which explains both the scientific example set and the build tooling.

For a project whose whole purpose is to bridge two ecosystems, a licence that is not one of the standard permissive or copyleft texts is a normal outcome rather than a red flag. What it does mean is that the obligations are not guessable, and the redistribution terms in particular are the part to check if you intend to ship a build.

The community around the project is small and stable: the website at tweag.github.io/HaskellR carries the documentation, and the Google Groups mailing list is where the questions go.

Where HaskellR is the wrong tool

Three limits are worth naming, and the first is the one that decides the question for most teams.

The release history is v0.10.5 on 2022-11-11, v1.0.0 on 2022-11-11 and v1.0.1 on 2023-05-22, while the repository itself was pushed to on 2026-06-29. The project is not archived, so the code is still being worked on, but there has been no tagged release since May 2023. A team that wants a versioned, supported dependency with a changelog is looking at a gap of more than three years.

The second is the shape of the boundary itself. An in-process foreign function interface is fast and it is also total: the two runtimes share an address space, the failure of one is the failure of the other, and the type systems have to be reconciled at every crossing. For some hybrid workloads that is exactly what you want, and for others, in particular where the R side is a long running service or where you want the two languages to fail independently, a process boundary with a wire protocol is the better design even though it costs a serialisation on every call.

The third is the pinning cost. Building this means having the right R, the right GHC and the right R packages for the snapshot you pick, and the three LTS specific stacks and shells in the repository are a hint of how many combinations somebody has had to support.

The honest reading is that HaskellR is a well designed answer to a problem that a lot of teams have and a few teams have exactly, and it is at the stage where the interesting work is maintenance rather than development.

Editorial conclusion

Adopt HaskellR if your work is split between Haskell and R, if the R side is where the statistics or numerical code already lives, and if the cost of an in-process foreign call boundary is acceptable. Do not adopt it for a project that needs a maintained release line, because the last tagged release is v1.0.1 from 2023-05-22 while the repository has still seen commits, and do not adopt it when a process boundary would serve better, since an in-process FFI couples the two runtimes in a way a service does not. Verify first which R and Stack snapshot your environment needs, since the repository ships three LTS specific stacks and shells, and read the LICENSE file rather than assuming the permissive terms of a typical Haskell project.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tweag/HaskellR on GitHub