Preface: The following post is about adventure games, Common Lisp and also about seven years old – lost and found in the drafts folder. I still liked it after all this years and therefore published it after all. Have fun.
After porting my adventure game Mork to Common Lisp I searched a way to release and share it to a community.
A Living Being
One truth that occured to me was, that programming in Lisp means interactive programming. Code is not architected or designed, it’s explored through a interactive interface into the running software. Code is behaviour that is researched by the coder; functions come to existence, they are formed and morph like a Morula.
Though languages like Ruby and Python know such a coding style, too, the interactively optimised functions will finally be written into a file to become a persistent part of the software.
Lisp is of a different feather. The interactive interface in Lisp is called a REPL – short for Read Eval Print Loop. It does exactly what the naming suggests: it reads user input, evaluates it with its known function context, prints the result and loops to a new prompt to take new input. Most users of a Unix operating system is this a very familiar concept as they use it on a daily basis in form of a terminal application.
In a Lisp REPL the function context is the software that is running. On upstart all connected libraries are loaded into the REPL and build the context. These functions may be updated or extended and new functions will be written. Though one could easily take a function from the REPL into a file and so build a library. But that library would finally be loaded back into the REPL to be executed – so why bother creating a whole bunch of libraries that form a software at all, if one could also persist the status of the REPL and therefore would get the current snapshot of the evolved software as it is?
A software written in Lisp is not unlike a living being. It evolves in a friendly environment and survives through adaptation. The REPL is this friendly environment. Without it, Lisp functions are dead and could also be written on paper for research purposes. But they won’t do anything there.
Pack up the whole world
I thought that it would be nice to wrap the whole REPL in its current state as a snapshot of my work into an executable to share the game; so the later enthusiastic gamer wouldn’t need to know how to setup and start a REPL by themself and load all the needed libraries.
I found a post by esden that helped me out here. It writes that Common Lisp itself provides the needed functionality without the need for an extern compiler. Is the REPL set and are all libraries loaded and the game is in a release worthy state just type
(sb-ext:save-lisp-and-die "Mork" :executable t :toplevel 'main-program-function)
into the REPL. The reader should switch Mork with the designated title of the software. The switch :executable makes the resulting software executable from the operating system so that a user doesn’t have to know that the software is written in Lisp at all. The parameter :toplevel controls the entry point into the software.
This is a very easy way to share your Common Lisp software with others. The target machine doesn’t have to have Common Lisp or any of the libraries installed. It comes as a whole. For very small software this means a large overhead, but for bigger software like a video game this is a rather comfortable way.
 Lisp files can be compiled. Through compilation a .lisp file becomes a .fasl file. But that cannot be executed. It is a optimised file to be efficient in loading and runtime behaviour.