Overview
For developers integrating Haskell into data science workflows or interactive documentation, the Jupyter notebook is the standard interface. Currently, there are two primary ways to run Haskell in Jupyter: IHaskell and xeus-haskell.
While both achieve the same end user experience (executing Haskell code in cells) their internal architectures represent fundamentally different engineering trade-offs:
IHaskell: “Do everything in Haskell.” It is a monolithic kernel that speaks the Jupyter protocol itself and drives GHC directly.
“Do everything in Haskell.” It is a monolithic kernel that speaks the Jupyter protocol itself and drives GHC directly. xeus-haskell: “Reuse the protocol machinery.” It delegates all protocol handling to a shared C++ framework (Xeus) and focuses only on connecting that framework to a Haskell interpreter (MicroHs).
This article explores those architectures side-by-side, with a focus on:
How they plug into the Jupyter kernel model.
What their design implies for performance, deployment, and library compatibility.
Which one is likely the better fit for different use cases (data science, teaching, documentation, client-side execution, etc.).
The Jupyter Kernel Architecture
... continue reading