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
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.
- 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
- 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
Regardless of how such standard functions as
LOAD are implemented, the
interactive style gives rise to a dynamic