Lili is a new Lisp dialect, which I initially developped for using it as a sort of central executive or macro language
in the Java - integration of an A.I. system called IPAL. Thus there already exists a kind of 'reference'-interpreter
implemented in Java (that incorporates some Lili-Java-interoperability features not inherent to the Lili language specification.) .
This is an intermediate information site on Lili for users and developpers (and people who consider to participate in
the development of Lili). It doesn't lay claim to completeness. Many important things (such as a BNF-specification of
the language) will follow later. I started work on this page on 03/26/2005 and will improve it, as soon as I find the
time for it. Corrections and annotations, questions etc. are truely welcome. Please send me an email. :)
In summer 2002 Christopher Loerken and I start work on a Java integration of the IPAL system. We decide to use a small
Lisp-like functional language as a macro-language for the system. Xmas 2002 I implement a rudimentary Lisp interpreter
in Java. In principle, this is merely an interpreter for the language described by John Mc Carthy (the inventor of Lisp)
in "Recursive Functions Of Symbolic Expressions, And Their Compuatation By Machine" (1960). This first Lili version was
limited, slow and awkward. From January to Summer 2003 I collaborate with Haiko Schol on the first language extensions
(like a simple multi-threading API, and a HTTP-Post client function, new datatypes etc.) and on speeding up evaluation.
Lili is registered as an open-source project at SourceForge.net and distributed under the GPL.
From summer 2003 the interpreter was used as a central executive for "HIPPAL" (the IPAL integration) and worked fine for
this purpose. Since autumn 2003 Lili is a one-person project (Right, that's me...).
Two major Lisp standards have evolved during the past decades: Scheme and Common Lisp. Lili is neither Scheme nor
Common Lisp but a new dialect. In principle, Lili is dynamically scoped but it allows for lexical closures. Although
it can in some parts be compared to Common Lisp (at least to its functional core), it is not as big as Common Lisp.
E.g., there are no built-in iterative constructs in Lili, and some features of Lili are not supported by Common Lisp
(multithreaded evaluation, HTTP-support, Pattern Matching, generic implicit "reducing" evaluation of binary functions,
partial evaluation of closures, ...). Some characteristics of Lili follow the example of the ML language adapted to
weak typing and a dynamic environment. A precise specification of the Lili language follows later.
The only interpreter for the Lili language existing until now is implemented in Java. Following from the fact that Java itself
(usually) is an interpreted language, execution of Lili programs in this interpreter is inherently slow. However, I was forced
to use Java for reasons mentioned earlier. The idea was to put a Lili-Java communication metalevel on top of the interpreter
(The "Symbiosis"-API; will be described later). Nevertheless the interpreter has been speed- and memory-optimized in many
respects. Because this was my first larger software project I reinvented the wheel more than just once. Today the Lili-
interpreter is approximately as efficient as JScheme (a Java-based Scheme interpreter written by Peter Norvig) (to be honest:
Lili is less memory-efficient but about 2.5-3 times faster than JScheme 1.4 as long as enough memory is provided for the
computation. It is circa 2-2.5 times slower than JScheme 6.1).
I have now started to read "Lisp in Small Pieces" and hope to get inspired by this book to find new ways for optimizing the
interpreter. In fact, there are a handful of Lisp interpreters and compilers implemented in Java, which are significantly
faster, but these projects follow totally different approaches (like translating lisp-programs first into code for a kind of
virtual machine, which itself can be implemented very efficiently in Java as it seems). Please have some patience with me...
Primarily I would like to thank Ute Schmid for giving me a reason to develop Lili. Integrating her IPAL system was the
initial motivation for Lili. She encouraged me additionally by not believing it could make sense to invent any new Lisp dialect
or -interpreter. Next, I want to mention Haiko Schol who supported the early stages of the development process strongly, and
Marc Schipper for having written a user documentation on Lili (now unfortunately deprecated). Some books and articles were
also important in a way that I couldn't have written Lili without reading them. I want to thank their authors: John Mc Carthy
for all his writing on Lisp, Peter Norvig for "Paradigms of Artificial Intelligence Programming. Case Studies in Common Lisp.",
Guy L. Steele Jr. for "The Art of the Interpreter", and for "Common Lisp-the Language", Paul Graham for "The Roots of Lisp.
A Draft.", L.C. Paulson for "ML for the working Programmer", R. Wilhelm and D. Maurer for "Übersetzerbau", A. Church for
"The Calculi of Lambda Conversion", and D. Flanagan for "Java in a Nutshell" - just to mention the most frequently used
books. To any persons I forgot I want to apologize me in advance.