CLISP has a facility for adding external modules (written in C, for example). It is invoked through clisp-link.

A module is a piece of external code which defines extra Lisp objects, symbols and functions. A module name must consist of the characters A-Z, a-z, _, 0-9. The module name “clisp” is reserved. Normally a module name is derived from the corresponding file name.

clisp-link needs a directory containing:

clisp-link expects to find these files in a subdirectory linkkit/ of the current directory. This can be overridden by the environment variable CLISP_LINKKIT.

clisp-link operates on CLISP linking sets and on module sets.

$ directory/lisp.run -M directory/lispinit.mem

$ clisp -K directory

$ clisp-link create-module-set module file1.c ...

$ clisp-link add-module-set module source destination

$ clisp-link run source module ...

Each module has two initialization functions:

name is the module name.

See also Section 30.1, “Customizing CLISP Process Initialization and Termination”.

Each module has a finalization function

name is the module name.

See also Section 30.1, “Customizing CLISP Process Initialization and Termination”.

Function (EXT:MODULE-INFO &OPTIONAL name verbose) allows one to inquire about what modules are available in the currently running image. When called without arguments, it returns the list of module names, starting with “clisp”. When name is supplied and names a module, 3 values are returned - name, subr-count, object-count. When verbose is non-NIL, the full list of module lisp function names written in C (Subrs) and the full list of internal lisp objects available in C code are additionally returned for the total of 5 values.

When name is :FFI, returns the list of shared libraries opened using :LIBRARY. When verbose is non-NIL, return the association list of DLL names and all foreign objects associated with it.

Function (SYS::DYNLOAD-MODULES filename ({name}+)) loads a shared object file or library containing a number of named external CLISP modules.

External modules for CLISP are shared objects (dynamic libraries) that contain the module__name__subr_tab variable, among others. This serves to register external functions which operate on Lisp-level structures with CLISP.

To use dlopen with modules, you should add -fPIC to the module's compilation options. Something like cc -shared -o name.so name.o may be needed to produce the shared object file.

To link in the “FFI” bindings for the GNU/Linux operating system, the following steps are needed. (Step 1 and step 2 need not be executed in this order.)

There are some tools to facilitate easy module writing.

DEFUN(MY-PACKAGE:MY-FUNCTION-NAME, arg1 arg2 &KEY FOO BAR) {
  if (!boundp(STACK_0)) STACK_0 = fixnum(0); /* BAR */
  if (!boundp(STACK_1)) STACK_1 = fixnum(1); /* FOO */
  pushSTACK(`MY-PACKAGE::SOME-SYMBOL`); /* create a symbol in the package */
  pushSTACK(`#(:THIS :IS :A :VECTOR)`); /* some vector, created once */
  pushSTACK(``MY-PACKAGE::MY-FUNCTION-NAME``); /* double `` means FUNCTION */
  VALUES1(listof(7)); /* cons up a new list and clean up the STACK */
}

When deciding how to write a module: whether to use “FFI” or to stick with C and modprep, one has to take into account several issues:

The following modules come with the source distribution of CLISP (but are not necessarily built in a particular binary distribution):

To use modules, read unix/INSTALL and build CLISP in directory build-dir with, e.g.,

$ ./configure --with-module=pcre --with-module=clx/new-clx --build build-dir

then run it with

$ ./build-dir/clisp -K full

This will create a base linking set with modules i18n, regexp and syscalls; and a full linking set with modules pcre and new/clx in addition to the 3 base modules.

See Chapter 32, Extensions Implemented as Modules for individual module documentation.