Barliman: an editor that guesses at the code you meant to write

What it does: synthesis in the middle of an edit, not in a batch

Barliman is a prototype smart editor that performs real-time program synthesis to try to make the programmer's life a little easier, and the project description calls it a prototype smart text editor. Three capabilities make up the core. Given a set of tests for a function, it tries to guess how to fill in a partially specified definition so that all the tests pass. Given a set of tests, it tries to prove that a partially specified definition is inconsistent with one or more of them. And given a fully or mostly specified definition, it attempts to prove that a partially specified test is consistent or inconsistent with it. The third is the one people miss, because a tool that only completes code is a completion tool, while a tool that also reasons about whether a test contradicts the code is doing something closer to proof assistance. The synthesis runs while you type, which is what makes it interactive rather than a batch tool.

The interface, and the red and black text convention

The screenshots use the list concatenation function append in Barliman's default miniScheme language as the running example, and they walk through the whole loop. The first screenshot shows a fully instantiated definition of append in the Scheme Definition pane, three tests with an input expression and an expected value each, and a Best Guess pane that is not editable by the user and contains the same complete definition. The second shows the empty editor window immediately after starting, where the writing begins with the tests, in true test driven development style. The third shows the three tests with the text in red, indicating that none of them pass, which is unsurprising because the function has not been defined yet. The convention is worth understanding because it is the only feedback the tool gives. All the text in the editor is black when everything is consistent and valid, and the definition, the test expressions and the expected values are each checked for syntactic validity and for consistency with each other.

The four stated purposes, and none of them is a product

The Purpose of Barliman section is four bullets, and reading them tells you what kind of artefact this is. The first is to test the hypothesis that even very modest or slow program synthesis can be useful, if it is part of an interactive conversation with a programmer. The second is to explore the utility of interactive synthesis. The third is to explore the design for such an interactive tool. The fourth is to try to inspire others to build similar tools, perhaps using radically different implementation techniques. So the deliverable is a research vehicle and a design study, and the interface is the experiment. That is not a criticism of the project, it is the design, but it does mean an evaluator should be asking what the experiments established rather than whether the editor is usable, because the maintainers themselves say the answer to the latter is no.

Language generality, and a default that is deliberately small

Barliman is general enough to handle multiple programming languages, and the user can even specify their own programming language, or change the semantics or syntax of one of the default languages. The default language is a small but Turing-complete subset of side-effect-free Scheme that supports recursion, list operations, higher order functions, multi-argument and variadic functions, and a few other features. Side-effect-free is the important constraint in that list, because a synthesis engine that had to reason about mutation would have a considerably harder search problem, and the restriction is what makes the demonstration tractable. The repository layout shows the experimentation behind that, with an interpreter_experiments/ directory, a cocoa/ directory holding the Mac implementation, paper_prototypes/ and interactive_editor_ideas/ directories, plus screen_shots/, animations/ and interesting_examples/ directories for the documentation, and a talk_examples_20161203/ directory with the code from the Clojure/conj talk.

The August 2026 news entry, and what it says about the project

The most recent news entry, dated 16 August 2026, is a short account of an experiment that failed. The author tried out LLM integration with Xcode to update the Swift-based UI to use the latest hotness, and it sort of worked, but he did not really understand the code as well as he wanted and generally felt yucky about it. So he reverted the LLM-assisted changes, updated the path to Chez Scheme by hand, and included an old-skool non-LLM Xcode IDE suggestion to remove a Swift compiler warning. Everything works as it used to, with the old lovely human-constructed duplicate code and barely working UI. The entry ends with the line that says it best, that yes the UI barely works, but it is their barely working UI. The last push to the repository was on 2026-08-16, the same day, so the project is being worked on, and the licence is MIT with the primary language recorded as Scheme.

The new version, and the collaborators working on it

The header says Barliman 4.3 is joint work with Greg Rosenblatt, and that a new version of Barliman is under development with collaborators in alphabetical order, Michael Ballantyne, Will Byrd, Greg Rosenblatt, Kanae Tsushima, Rob Zinkov, and a coming soon. So the current line is 4.3 and the next one is in progress. The history section also records the first talk on Barliman, presented by Will Byrd and Greg Rosenblatt at Clojure/conj 2016, which is online along with the example code from the talk, and the creation of a Barliman Google Group, with a planned Google Hangout series on Barliman, relational interpreters and program synthesis. The 2016 entries are the last substantial news items before the 2026 one, which tells you how quiet the public record has been.

The repository layout, as a picture of how the work is done

The top level of the repository is organised by the stage of the work rather than by module, and that is itself informative. There is cocoa/ for the Mac implementation, interpreter_experiments/ for the reasoning engine, paper_prototypes/ for the earlier throwaway work, interactive_editor_ideas/ for the design thinking, screen_shots/ with a dated subdirectory of the 2016 June captures, animations/ for the animated walkthroughs, interesting_examples/ which the README now points to for the most recent examples and screenshots, and talk_examples_20161203/ for the conference code. There is also a.io.livecode.ch/ directory, a.gitignore, the LICENSE and the README. The MIT licence applies. Nothing here is packaged or published, and the repository has no releases, which is consistent with a project whose distribution channel is its git history and its conference talks.

What it is worth to look at today

The honest summary is that Barliman is a research prototype whose most valuable output is the design of the interaction, documented in screenshots, animations and the 2016 talk, rather than a tool to install. The three capabilities are still the right specification of what an interactive synthesis tool should do, and they map onto a well-known failure mode in test driven development, where you know what the function should do but not how to write the body. The current state of the code, with the Swift UI on a manually maintained path to Chez Scheme and a UI the author calls barely working, tells you that the project is a few weeks of attention away from working rather than years, and the 2026 entry shows the maintainer is still engaged with it. For an evaluator, the useful move is to read the interactive_editor_ideas/ directory alongside the screenshots, since the design questions the author poses, about which colours to use, which text fields to highlight and how to make it clear which part of the code is failing and why, are the actual research contribution.

Editorial conclusion

Barliman suits a programming language researcher or a systems programmer who wants to see program synthesis as an interactive loop rather than as a batch job, and who is prepared to read Scheme to understand how it works. It is the wrong choice for a production editor, since the project calls itself a prototype and the maintainers describe the current interface as barely working, and a poor fit if you need it to be a plugin for a language with modern tooling, because the default language is a small side-effect-free Scheme subset and everything else is your problem. Before you evaluate it, read the news entry from August 2026, because the maintainer describes reverting an LLM-assisted rewrite of the UI and going back to hand-written code, which tells you what kind of project this is.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. webyrd/Barliman on GitHub