The effects bibliography is a single Markdown file, curated by pull request

What the repository is, and how small it is

The effects bibliography is a single Markdown document with an unusual amount of care in it. The top level of the repository holds README.md, a.lycheeignore file and a.github directory, and there is no code, no build system and no package manifest. The whole artefact is a list.

The README opens by saying what it collects, a collection of research papers and other resources related to the theory and practice of computational effects, and the topic tags say the same thing in three words: algebraic-effects, bibliography, effect-handlers. The project is maintained by Jeremy Yallop, whose name appears as an author of one of the listed implementations.

Two details in the repository layout say more about how it is run than the prose does. The.lycheeignore file is the ignore list for lychee, a link checker, which implies that a workflow in the.github directory walks the links in the bibliography and fails when one breaks. For a document whose entire value is that its links work, that is the correct engineering investment, and it also means the list is a maintained artifact rather than a snapshot someone wrote once. The second detail is that the working branch is master and the repository publishes no releases, so there is no version to cite, only a branch that moves.

The contribution rules are three lines long

The instructions section is short and entirely about style, which is what you would expect from a file that many people contribute to.

Pull requests are welcome, and the README also points out that you can edit the file directly from the browser, which lowers the barrier for people who do not want to clone anything. The two remaining rules are about consistency: keep the formatting consistent with the rest of the file, and end a line with a double space to force a line break. That last one is a Markdown detail, since a single newline in Markdown is just a space, and it tells you the entries are written as prose paragraphs inside a bullet item rather than as nested list structure.

The consequence of a rule set this light is that the file's coherence comes from the maintainer and the reviewers rather than from tooling. There is no schema for an entry, no generator, no validation beyond the link checker. The result is a document that is easy to contribute to and easy to read, and also easy to make inconsistent, and the only real quality control is a human reading a diff.

That is a deliberate trade, and it is worth naming as such. A bibliography that requires a pull request per line is hostile to the people with the most to add, and a bibliography that accepts any edit is a mess within a year.

What the software section actually maps

The software section is the part of the file with the most information, and it is structured consistently: a bold name, a one line description, the authors or the organisation, and one or two links to the project, a paper, or a tutorial. The entries are the actual implementations of the idea, and the spread across languages is the interesting part.

The functional languages appear with several designs rather than one. Eff, by Andrej Bauer and Matija Pretnar, is described as a programming language with algebraic effects and handlers, and Coop, by Andrej Bauer and Danel Ahman, is a prototype language for programming with runners. Effekt, by Jonathan Brachthäuser, Philipp Schuster and Klaus Ostermann, is a language with lexical effect handlers and lightweight effect polymorphism, and Fram, by Patrycja Balik and Piotr Polesiuk, adds lexically-scoped handlers and generalized labelled parameters. Desk, by Ryo Hirayama, is statically typed with an effect system based on set-operation, and Flix, by Magnus Madsen, Matthew Lutze and Jonathan Lindegaard Starup, adds inference based on Boolean unification.

The Haskell ecosystem has its own cluster of libraries, including Extensible effects by Oleg Kiselyov, Polysemy by Sandy Maguire, Fused effects by Rob Rix, EvEff by Daan Leijen and Ningning Xie, and Heftia by Riyo Yamada, described as semantically-sound higher-order algebraic effects and handlers. The ML and dependently typed family includes F*, from Microsoft Research and Inria, aimed at program verification, and Idris Effects by Edwin Brady, inspired by Eff.

The rest of the list covers a wide range of hosts. Multicore OCaml is an effect handlers extension for OCaml, now incorporated into OCaml 5. Scala Effekt and atnos-org/eff bring the idea to the JVM, Unison calls its equivalent abilities and is inspired by Frank, and Pyro, from Uber AI Labs, is listed as a deep universal probabilistic programming language. The systems level entries are WasmFXtime, a Wasmtime fork with effect handler support, Wasm/k, WebAssembly with first-class continuations, Lexa, compiled to stack switching, and a set of C and C++ implementations including libhandler, libmprompt, cpp-effects and an experimental C++ runtime effect system.

The Rosetta stone is where the actual comparison lives

The README points readers to a companion project for the thing a bibliography cannot do. The Effects and handlers Rosetta stone, hosted by the effect-handlers organisation, is described as a comparison of how computational effects and handlers are implemented in various programming languages.

That distinction is the point. The bibliography tells you that implementations exist and who made them. The Rosetta stone tells you how they differ, in terms a reader can act on when choosing a language or a library for a project. A flat list of entries with no axes of comparison is a starting point for research, not an answer.

For an engineer picking an approach, the combination works better than either alone: use the bibliography to find the set of candidates, then use the Rosetta stone to see what each one actually does, and only then open the individual project pages. The links in the bibliography point to homepages, source repositories, hackage packages, papers and, in a few cases, tutorial articles, such as the effects tutorial in the Desk repository and the Effect Handler reference in the Unison language reference.

Maintenance, licensing and what this project is not

The last push to the repository was on 2026-04-30, so the list is being maintained, and the project publishes no releases, which is normal for a document like this. The topical coverage is broad enough that entries accumulate rather than churn, and the additions you would expect, a new effect system paper or a new implementation, arrive as pull requests from the people who wrote them.

The licensing is the awkward part, and it is worth a paragraph of its own because it is easy to miss. The repository has no LICENSE file in its top level, and the licence is recorded as unknown. The content is a list of other people's work, with short descriptions, and a great deal of the text is written by contributors rather than by the maintainer, so the terms under which you can copy the descriptions are not stated. Reading a list is not the same as copying it, but if you want to reuse an entry, for example in a course reading list or a slide, the safe path is to write your own description and link to the original.

The second limitation is that a bibliography is not a survey. There are no dates on the entries, so a ten year old prototype and a language people use in production look identical. There is no indication of activity, maintenance or adoption, and no status field to distinguish an experimental prototype from a shipped implementation. The descriptions are one line long, which is exactly right for a list and exactly wrong if you are trying to understand the tradeoffs.

The third limitation is the one the link checker cannot catch. A link that resolves is not a link to a working implementation. Implementations in this area are research artefacts with a short half life, and a maintained list of living links can still point at software that no longer builds, at a paper that has been superseded, or to a language whose design changed substantially after the entry was written. Anyone using this list as a survey of the current state of the art should expect to spend an hour checking that the things they pick are still maintained, and the project itself gives no way to filter for that.

Editorial conclusion

Adopt the effects bibliography as a starting map if you are new to algebraic effects and effect handlers and want a single page of implementations across languages, and treat the effects and handlers Rosetta stone as the place to go for actual comparison. Do not adopt it as a ranked or dated survey, because entries carry no year, no status and no criteria, and the repository has no release history to pin. Verify first by opening two or three of the linked implementations and reading their own documentation, since the list is only a set of pointers, and by checking whether the licence file situation still holds before you copy any of the text, because the repository currently carries no licence file.

Frequently asked questions

Official sources

1. Issues
2. README
3. yallop/effects-bibliography on GitHub