Why Lisp?

There is a number of reasons why Common Lisp was chosen as the language for CRAM.

Due to its powerful macro mechanism Lisp is known to be good for implementing domain-specific programming languages. This characteristic was extensively used during the implementation of CRAM: a new reactive planning language CPL (CRAM Plan Language) was developed for CRAM. It is used for programming cognition-enabled control systems and is based on RPL.

In Lisp, code is represented using standard data types (it is, basically, a List). Thus, code can be assigned to a variable, it can be generated at run-time, i.e., code that was generated on the fly can be executed straight away, using the powerful macros mechanism custom code can also be generated at compile time, and as any other data object code can also be easily modified by other code. That enables for automatic generation and transformation of robot plans.

Symbol is a built-in type in Lisp. In conventional programming languages symbolic data would usually be represented either as strings or enumerations, which both have their drawbacks. On the other hand, the existence of type “symbol” makes Lisp prefect for representing and processing symbolic data, and, in combination with the macro mechanism, makes it convenient for writing symbolic reasoning systems. CRAM has a custom Prolog interpreter (also written in Lisp) that can perform logic reasoning and, in addition, as opposed to traditional Prolog, use specialized inference methods (based on math etc.) for the cases when logical inference has a too large of a search space.

Historically Lisp was an interpreted language. Although the compiler used in CRAM (Steel Bank Common Lisp) compiles every chunk of code unless explicitly asked to interpret it, Lisp is still very convenient for rapid prototyping. It has an interactive shell where new pieces of code can be immediately tested. It also supports hot swapping: it is possible to make changes in a chunk of code and recompile it at run time and the changes will immediately take place, without having to stop the program execution.

The last but not the least reason for choosing Common Lisp is that it is a very powerful and flexible language and is fun to program with. In addition to supporting functional programming, it also has the advantages of the object-oriented programming languages, as it supports such concepts, as classes, multiple inheritance, function overloading etc. through Common Lisp Object System (CLOS), which is its built in facility.

In terms of efficiency Lisp is generally faster than many languages, such as Python or Ruby, but, slower than, for example, C++ or Java 6 (based on the benchmarks from http://shootout.alioth.debian.org/ by the time of writing). However, CRAM runs on a robot in real-time and the robot usually has enough time to think about its future actions while performing current actions: physical execution of actions is in most cases slower than the computation, so efficiency is not a major concern in CRAM. In addition, SBCL has many possibilities to improve code using the optimization declarations when really needed.

The choice of a programming language is, of course, always a trade-off of the advantages and disadvantages of using a certain language for a certain problem. Lisp for CRAM is not an exception.

One of the major problems with Lisp is that it is not widely accepted in the computer scientists community. Due to its functional programming nature it is really hard to get into for people that are used to the traditional imperative programming way of thinking. In the recent years though functional programming seems to finally be finding acceptance in the wider masses, so there is a good perspective also for Lisp.

Despite the SBCL compiler being an industrial strength product, as a language, Common Lisp was not designed with industry in mind. Its dynamic typing system, loose encapsulation, allowing for side-effects and the fact that it gives the programmer so much freedom and does not put many restrictions on the programming style, results in Lisp sacrificing robustness and security for expressiveness and ease of use. Generally, Common Lisp is more suitable for rapid prototyping and testing research approaches than for writing an industrial application. However, please note that CRAM does not claim to be an industrial library and is in fact a research tool.