Common Lisp/Implementation Issues

Common Lisp is a specification which has many implementations. Each of these implementations has met the CL specification in different ways. This means that, almost certainly, the way that a Lisp implementation performs certain tasks (start up, shutdown, debugging, delivery, scripting, etc.) will be different. In addition, it is common for certain implementations to have special features that have not been adopted by the entire CL community but are very useful in their own right. This chapter will provide a short/selective sampling of using popular Common Lisp implementations and common usage.

Application Delivery

The open source community is very active in the Common Lisp world (as it is in “hacker” languages). As such, the most common way to distribute Common Lisp software is via source archives. Often these source archives use the ASDF package manager. This has a small drawback that the user has to be proficient enough to install a Lisp implementation and build the package. In addition, some people wish to close source their program. For these purposes there are other methods of distributing programs.

Dumping a Lisp Image

One way to deliver a Lisp application is to provide a dump of the Lisp image. This has traditionally been the route to provide a “finished” program to users. This is basically the same as providing an executable of your program. Often, all you will see is a opaque, monolithic file that contains your program (and almost ubiquitously the entire Lisp system). While this allows developers to hide the application source to the user, it also solves the problem of the user having to find and install a lisp implementation. Since the application is just an executable, all the user needs to do is run that program. Lisp images are not portable, however, and would need to be built for every system type you want to support.

SBCL

To produce a Lisp image in SBCL use SAVE-LISP-AND-DIE.

;; Make a Lisp image.  Execute with sbcl --core lisp-image.core
(save-lisp-and-die #p"lisp-image.core")
;; Make an executable Lisp image.  Execute with ./lisp-image
(save-lisp-and-die #p"lisp-image" :executable t)

There are many other options you may use when building your image. See the user manual to see what they do.

to load Lisp image when Lisp starts use runtime option :

--core corefilename

so in console :

/usr/local/bin/sbcl—core lisp-image.core

CLISP

To save image in CLISP use :

(saveinitmem "/home/you/yourLispDir/lispImage.mem")

Afterwards if you want to use it load it like this ( in console ) :

clisp -M lispImage.mem

Portable byte code

Some Lisps, such as CLISP, produce portable byte code. This means that you can build your program on one system and send it to a user who can then run it on their CLISP implementation. This solves the problem of hiding source from the user. Of course the user still needs to install CLISP, but it is luckily one of the easiest to install.

Scripting

One often desires to write Common Lisp “scripts” in much in the spirit of Perl, Python, and Bash. For such an application you often have to worry about certain factors that Common Lisp users often don't worry about such as:

• Start up time needs to be very fast. Often scripts are run on small inputs for simple problems so starting the Lisp image must be fast or it will become the bottleneck.
• Memory usage needs to be very low. Often users will run tens to hundreds of scripts at a time.

Both of these factors are commonly ignored when producing a Lisp system. After all, Lisp systems are typically long running (so start up speed is of little importance) and form their own computing environment (so only one instance need be running at a time, making memory use of little importance). There are, however, several implementations that can act as scripting platforms. When properly configured, SBCL, CCL, and CLISP all have relatively fast start up times. CLISP and ECL run with fairly small memory footprints.

Calling a Common Lisp Server

This is a question that comes up now and then on certain newsgroups: “How can I circumvent my Lisp's excessive start up time and/or memory usage by calling a Lisp server instead of a starting a new process.” Often the user is not utilizing the Lisp implementations features fully, which leads them to this solution. Usually, creating a Common Lisp server is not really necessary because the techniques demonstrated in the Scripting or Dumping a Lisp Image sections are enough to fix these problems. There are however, times when this may actually benefit you. A Common Lisp system is a very big thing; just loading such a large thing can prove to be a bottleneck for some applications.

Embedding Common Lisp in Another Language

Calling Lisp from C

ECL is a full, stand alone CL implementation with the added feature that it is embeddable in any project that can make C function calls. Originally conceived as a way to get some Lisp in C applications without a huge footprint, it has quickly grown to a full implementation in its own right.

Calling on an Underlying VM

There are very few Common Lisps that run on top of a virtual machine. Those that do have the ability to use libraries from other languages that also use that VM. ABCL is a Common Lisp that runs on the Java VM. ABCL has the ability to access any part of Java, which means that there are a plethora of popular libraries out there for you to use.