Re: preprocessor-based Common Lisps

[John Diamant <hpfclp!diamant@hplabs.HP.COM>]

Since I brought up the subject of preprocessors in Common Lisp implementations,
I have been asked to describe the HP preprocessor.  Here is a small paragraph
written by one of the implementors of the preprocessor (Jerry Duggan):

> HP chose to implement its Common Lisp system based on a preprocessor
> model.  The preprocessor takes "raw" Common Lisp code, expands macros,
> and translates this lisp code into an internal form which is used as
> input to both the interpreter and compiler.  Additionally, the
> preprocessor may perform optimizations on the Lisp code.  There were
> three reasons why the implementation was done this way.  First, it was
> a means to ensure consistent semantics between the interpreted and
> compiled code, since both the interpreter and compiler use the same
> input.  Second, the preprocessor performs all the analysis required
> for lexical scoping, so the implementation of lexical scoping was easy
> and efficient in the interpreter, and closures could be compiled
> efficiently.  Third, all Common Lisp forms are translated into a basic
> internal form which has about thirty different constructs.  The small
> number of constructs limits the allowed input to the interpreter and
> compiler, making them both more manageable.

The optimizations that Jerry refers to are primarily source-level
translations, as opposed to machine language optimizations.  Since the
preprocessor is limited to source and interal representations, it cannot
perform optimizations directly on machine code since that hasn't been
generated yet.

Preprocessed code can be traslated back into equivalent source code, but that
source code may not be the same as the original source, because of the
source-level optimizations (including macro-expansion) done on it.  We added
a declaration corresponding to the speed declaration for the interpreter
(technically the preprocessor when called from the interpreter), so that a
different degree of optimization can be enabled for interpreted and compiled
code.


John Diamant		diamant%hpfclp@hplabs.hp.com