This is a fast interpreter of the Unlambda programming language, a minimal esoteric functional language based on combinatory logic.

A C99 compiler and Make are required.

make

To try it:

$ printf '%s\n' '```.O.Kri' | ./unlambda
OK

$ ./unlambda [options] [program-file]

If program-file is not specified, the Unlambda program is read from standard input.

Options:

• -h: Print help and exit.
• -v: Print version and exit.
• -v0 (default): Do not print any debug information.
• -v1: Print some statistics after execution.
• -v2: Print logs for major GCs.
• -v3: Print logs for minor GCs.

Compared to unl.c by Emil Jeřábek, which itself is 50-100 times faster than the official c-refcnt interpreter, this interpreter was 2.0-2.5 times faster in the measurements below.

Peak memory is not uniformly lower: the fixed-size young-generation regions have a noticeable cost in the smaller benchmarks, while the allocation-heavy ELVM benchmark uses slightly less memory than unl.c.

Measurements were taken on an AMD Ryzen 7 8845HS under WSL2. Both interpreters were compiled with GCC 15.2.0 using -O2. The table reports median elapsed time and peak RSS over seven runs for Adventure and Lisp and three runs for ELVM.

To achieve this performance, this interpreter introduces several new combinators (B, C, T, and V) used only internally to substitute expressions under evaluation by pattern matching. The following substitution rules are implemented:

     `S`Kf -> `Bf    where ```Bfgx = `f`gx
   ``Sf`Kg -> ``Cfg  where ```Cfgx = ``fxg
   ``SI`Kx -> `Tx    where   ``Txy = `yx
 ``S`Tx`Ky -> ``Vxy  where ```Vxyz = ``zxy

(Note that V is the "pair" combinator (also known as "cons") and is unrelated to Unlambda's built-in v ("black hole" function).)

For example, when the first argument is given to S, if it is a partial application of K (with one argument f given), it is replaced by `Bf.

These auxiliary combinators use less memory and evaluate faster than the original SKI-only combinator expressions.

The object graph of Unlambda execution does not cycle, so memory management can be done using reference counting. In fact, the c-refcnt interpreter and unl.c both use reference counting.

However, since Unlambda frequently creates and destroys objects, reference counting can be quite an overhead. Also, optimizing things like omitting reference counter operations where possible, or overwriting and reusing objects when the counter is 1, as unl.c does, can make the code more complicated.

Therefore, this interpreter uses a generational garbage collector. For the young generation, it uses two regions of 256k objects and performs copying GC. Objects that have survived this minor GC twice are moved to the old generation region. When the old generation area is full, a mark-sweep GC is performed on the entire heap as a major GC.

Generational GC is very effective in Unlambda, often collecting more than 99% of objects in minor GC. In benchmark measurements, GC accounted for about 1% of the overall execution time.

In general, generational GC requires a write barrier to keep track of references from the old generation area to the new generation area. But in this interpreter, once an object is created, it is never rewritten, so references from the old generation to the new generation do not occur. Since no write barrier is needed, the evaluator can be written without worrying too much about GC (although copy GC changes object addresses).

This software is released under the MIT License.