"We must all hang together, or most assuredly, we will all hang separately." -Ben Franklin
In general, a Lisp implementation provides a Lisp top-level that allows code to be loaded into
it using the function
Any programs loaded in this way and called from top-level are under
the control of the Lisp top-level.
Exactly what kind of files can be loaded with
implementation dependent. In some implementations,
files produced by external operating system-specific compilers. In
other implementations, a new top-level must be constructed which
includes the external program.
However, there is nothing in the definition of Common Lisp that specifies that all programs
must be run from the Lisp top-level. For example, Lisp could be
provided as a library of utilities that are linked to some other
controlling program. There are some implementations that provide such
a library, while others have the ability to effectively create one for
the programmer, based on the Lisp source files for a specific
In any case,
LOAD and/or the Lisp compiler must be informed about functions or other
operations to be defined in a different language. Exactly how this is
done is implementation and operating-system specific. The various
mechanisms are collectively known as foreign-function
interfaces. Usually, these involve some specification of:
Some possible complications occur if:
- what other language is being used for each foreign utility to be
used (so that the compiler can use the correct calling convention).
- the arguments and return values types for the function.
- The Lisp implementation uses utilities that are inherently
incompatible with utilities used in a program to be linked with Lisp.
This is rare.
- Lisp data is to be passed directly to external utilities and kept in
variables within the external program. In some cases this, can
interfere with Lisp memory management because:
Most Lisp implementations provide special facilities for dealing with
- The memory manager of some Lisp implementations have the ability to
move data within memory (to obtain better performance), so Lisp data
pointed to by foreign programs could move, resulting in pointers
that are no longer valid.
- The Lisp memory manager can keep track of which data is being
used within the Lisp system, but may not be able to keep track of data
that is being used by external programs.
An alternative mechanism for using applications involving multiple
languages is to use an object-based inter-object protocol. This is
done in such systems as CORBA Object
Request Brokers (ORBs), ILU, and OLE, and
these will work with many Lisp implementations.
In an inter-object protocol, a programmer specifies information
about the interface between program modules, and indicates where the
modules are to be found. The various modules might be:
The issues involved with such inter-object protocols are largely the
same for applications written in any combination of languages,
including those that are partly written in Lisp.
- within the same process (i.e. executable application) as Lisp -- in
which case the foreign function interface discussion, above, is
- in different processes on the same machine.
- on different machines connected over a network.