From: Jürgen Böhm
Subject: Lisp compiler question
Date: 
Message-ID: <fkh2c0$82g$03$1@news.t-online.com>
Hello,

  I have written a small compiler for a basic subset of (Common) Lisp,
including full lexical scoping. What the compiler is missing still is an
adequate check against syntactically malformed input programs.
   Such input will currently mostly produce an unenlightening error like
"cannot take car of an atom" because the error in the input so to say
"propagates its way" into some basic lisp function used by the compiler.
   To remedy this, I want to add some syntax check, for which I see
basically two possibilities:

A) Syntax check at the beginning of the (several phase) compilation
B) Syntax check interspersed into one (or several) of the existing
compiler phases

(The compiler phases I currently use are: 0) Variable Renaming
1) Free variable analysis 2) Write to non-closed variables elimination
3) Closure Conversion 4) Code Generation)

Which of the two possibilities A) or B) from the above is more closely
to the way a "professional compiler" like SBCL or the like is handling
this problem?

Personally I tend to more to A) because

i) there is a clear cut separation from the partly quite intricate
manipulation of the source in the following phases
ii) it is therefore easier to implement a separate logic for syntax
checking - essentially one recursive walk through the program.

With thanks in advance for any answers

J�rgen B�hm

-- 
J�rgen B�hm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?"  R. Thom

From: Juho Snellman
Subject: Re: Lisp compiler question
Date: 
Message-ID: <87tzm2pm2w.fsf@vasara.proghammer.com>
J�rgen B�hm <······@gmx.net> writes:
> Hello,
> 
>   I have written a small compiler for a basic subset of (Common) Lisp,
> including full lexical scoping. What the compiler is missing still is an
> adequate check against syntactically malformed input programs.
>    Such input will currently mostly produce an unenlightening error like
> "cannot take car of an atom" because the error in the input so to say
> "propagates its way" into some basic lisp function used by the compiler.
>    To remedy this, I want to add some syntax check, for which I see
> basically two possibilities:
> 
> A) Syntax check at the beginning of the (several phase) compilation
> B) Syntax check interspersed into one (or several) of the existing
> compiler phases
[...]
> Which of the two possibilities A) or B) from the above is more closely
> to the way a "professional compiler" like SBCL or the like is handling
> this problem?

SBCL will do syntax checks on macros when they are expanded, and on
special forms when the source is translated from sexps to an
intermediate representation. But note that in SBCL it's not just a
matter of having a syntax check phase happen first, followed by other
phases.  E.g. it's possible that during optimization new code is
inlined into a function, causing a new round of translation (and thus
syntax checking) of the inlined source code.
 
> Personally I tend to more to A) because
> 
> i) there is a clear cut separation from the partly quite intricate
> manipulation of the source in the following phases

You might want to reconsider doing intricate manipulation directly on
source code. Raw sexps don't work very well as the intermediate
language for a compiler.

-- 
Juho Snellman
From: William D Clinger
Subject: Re: Lisp compiler question
Date: 
Message-ID: <5268fc36-60e9-4631-9f89-1c978bcbeffc@t1g2000pra.googlegroups.com>
Jürgen Böhm wrote:
> > A) Syntax check at the beginning of the (several phase) compilation
> > B) Syntax check interspersed into one (or several) of the existing
> > compiler phases....
> >
> > Personally I tend to more to A)....

Me too.

Juho Snellman wrote:
> You might want to reconsider doing intricate manipulation directly on
> source code. Raw sexps don't work very well as the intermediate
> language for a compiler.

Processed s-expressions work well enough for Twobit.

Will