Compiled and Interpreted Lisp -- Evaluation in Lisp

Summary: Common Lisp supports both compiled and interpreted programs. Some implementations also use "virtual machine code" or "byte code".
up
prev next

search
site map
navigate
about

<*LISP*>
<*learning*>
<*applications*>
<*tools*>
<*community*>
<*references*>
<*systems*>
<*related*>

top-level
syntax
evaluation
environment
objects
dynamic
typing
memory
macros
performance
3GL
history
compare
combine

From the beginning, Lisp has supported interactive programming development, in which programs or pieces of programs could be quickly tried out. This contrasts with the FORTRAN batch style of program development which came from the punch-card days in which development proceeded by repeatedly editing the program, processing the program, and running the program from start to finish (or crash). The interactive style has been adopted to varying degree by other languages such as Smalltalk.

A significant consequence of this development style is that programs with complicated state can be developed more easily, with the developer testing new code without restarting the program. When problems arise, the program can be fixed and continued, without the need to rebuild the program state.

ANSI Common Lisp requires that all implementations support this development style by providing a program development environment which can interactively run arbitrarilly short or long programs, invoke the compiler, and load new definitions (whether source or previously compiled) -- all without loosing current state such as the values of global variables or function definitions.

It is not specified whether interactively running code may "interpret" the source directly, or whether it should first "compile" the code into machine instructions. The distinction is somewhat blurry:

Lisp was designed to write programs which can efficiently manipulate other programs. In its default configuration, the Lisp reader translates Lisp source text into an efficient list representation of the program at the time the program is read. Lisp programs can then be repeatedly "run", (i.e. evaluated) by processing this pre-parsed representation of the source. This contrasts with those Perl and Smalltalk evaluators which always treat source as text, requiring repeated parsing and/or hashing of identifiers.

Many operating systems today have emulators which "interpret" the machine instructions for other types of computers, allowing identical copies of "compiled" programs to run on multiple platforms. Thus the compiled code is interpreted by the emulator. Even "native" machine instructions are interpreted by microcode or hardware interpreters. In short, at some level, all software on every machine is interpreted.
ANSI Common Lisp requires that each implementation provide a compiler which obeys certain rules. The standard recognizes the different possibilities for implementation. Some systems always produce "virtual machine" instructions (called byte-code) which is portable across all platforms supported by the implementation. (This is what Java does.) Other system always compile to "native" machine instructions. Some systems do both. All implementation must at least perform some minimal compilation such as expanding macros so that they do not need to be expanded again at run-time.

Regardless of how such standard functions as EVAL, COMPILE and LOAD are implemented, the interactive style gives rise to a dynamic language system.