Most functional interpreter

Ondřej Adamovský

Judges' comments:

To use:

make prog
./prog file.unl


./prog spam.unl

./prog sierpinski.unl | less

./prog advent.unl

Selected Judges Remarks:

Even after pre-processing and indenting, the C code of this entry is about as understandable as the Unlambda code.

Pretending that we don’t know a bit of functional programming :) and lacking a better way to understand the entry but to fuzz it, we stumbled on a string of bytes which crashed it:


Functional programming is not a panacea against core dumps, after all.

Author’s comments:

»A highly structured state state machine«


The purpose of this program is to allow you to play Colossal Cave Adventure as implemented by Kunihiko Sakamoto. As that was written in Unlambda programming language designed by David Alexander Madore it has to be an Unlambda interpreter.


The program grew a bit too long so I had to use several macros to downsize it. That unfortunately reduced my options for program layout. I decided to separate it into two portions. The initial macro section where I had limited resources and you should disregard its shape, unless you like it, and the rest is a separator in the form of a single line followed by a section signifying the function of the program, a block with removed shape of lambda character. Even the official IOCCC size tool acknowledges this: When you call ./iocccsize -i <prog.c, using the 2019 version of iocccsize, iocccsize returns 955, which is the Unicode codepoint of the λ character.

It might be a surprise for you that according to the IOCCC size tool the program is actually a oneliner. It certainly was for me. I like to think the tool is overwhelmed by the sheer length of the dividing line and totally overlooks the rest of the program.


When built directly


the program (prog) accepts a single parameter with the name of an Unlambda program. You can download the Colossal Cave Adventure (the advent.unl file) and run it like this

./prog advent.unl

You can also try other programs from the Web. Many example programs are in the official Unlambda distribution on the Unlambda homepage. The most complex programs there are entries from quine contest.

There is an alternative build path that requires IOCCC size tool to complete. Put the tool source iocccsize.c in the project directory and call

make identify

It will build the tool and use it to build an alternative program prog2, which in turn will produce an Unlambda program identify.unl. make identify runs this program to identify itself.

The base program (prog) implements an interpreter of Unlambda 2.0. It recognises all its builtins (k, s, i, v, c, d, .x, e, @, ?x and |) including the syntactic sugar function (​r​) and formating properties in the form of ignoring whitespace and comments to the end of line introduced by the # character.

In case of wrong usage (missing Unlambda program file or missing parameter) or use of an unseekable Unlambda program source if it uses the c function, the program returns message fail. It also informs you about syntactic errors in the Unlambda program should there be any (but only when the execution reaches them).

The Unlambda source file may contain several Unlambda programs. The interpreter will run them all in sequence.


If you want to familiarise yourself with the language, visit its Wikipedia page for a brief introduction or its homepage for an indepth discussion. For further reading you can visit Wikipedia pages on Lambda Calculus and Combinatory Logic.

You can also play with an online interpreter by Github user inazz. There you can debug one of example programs provided or try your wits in writing your own.


Here are some pointers where to start when trying to understand the interpreter:

Obfuscation sources

More on this in the Spoilers section.

Build notes

The program does not require any special treatment by compilers. Some warnings had to be suppressed when compiling with -Wall -Wextra -pedantic. Those were produced because of the formatting of the source code, not any programming technique. Compilation with -Weverything produced many more warnings, but those are only relevant for multi-source-file projects and some are really questionable (e.g. -Wdisabled-macro-expansion).


Development was done on Debian 9 on x86-64 architecture using mainly Clang 3.8.1-24 and GCC 6.3.0. The source is C11 compliant and does not use any special properties except the following:


Identification spoiler

The alternative build path make identify output commemorates a previous IOCCC winner which uses similar methods to mess with the size tool.

Judges remarks spoilers

It is not a bug, it is a feature. :)

The crash is caused by a stack overflow. Conventional Unlabmda interpreters implement the Unlambda execution stack using data structures on the heap. This interpreter uses the C call stack for this purpose. In a conventional interpreter, the judges program would consume memory until the user (or the operating system) would lose patience. The C call stack is usually of a limited size and protected, so this interpreter crashes, when the judges program depletes the stack. You can always increase the maximal stack size through the system settings (on Linux) or compiler options (on Windows) if your Unlambda program needs it. Nevertheless, it will not help the judges program which quickly depletes any limit you define.

The judges, pretending not to know what they are doing, created a program that grows Unlambda execution stack indefinitely. You may consider it an Unlambda antipattern. Normally, infinite cycles in Unlambda work by creating two functions and applying one to the other which creates further functions to apply. The application of the function frees its position on the stack. This program builds one ever growing function that will never be complete and able to be applied.

Creative Commons License

© Copyright 1984-2019, Leo Broukhis, Simon Cooper, Landon Curt Noll - All rights reserved
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.