"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 LOAD. 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 LOAD is implementation dependent. In some implementations, LOAD can handle .o, .so, or .dll 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 application.

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:

• 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:
  • 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.
  Most Lisp implementations provide special facilities for dealing with these issues.

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:

• within the same process (i.e. executable application) as Lisp -- in which case the foreign function interface discussion, above, is relevant.
• in different processes on the same machine.
• on different machines connected over a network.