[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-Lisp@su-ai.arpa
- Subject: some questions
- From: email@example.com
- Date: Thu, 5 Jun 86 15:11:25+0900
Date: Fri, 30 May 1986 03:29 EDT
From: Rob MacLachlan <Shasta!RAM@>
Subject: Some questions
In-Reply-To: Msg of 30 May 1986 00:21-EDT from miller.pa at Xerox.COM
Date: Friday, 30 May 1986 00:21-EDT
From: miller.pa at Xerox.COM
To: Common-lisp at SU-AI.ARPA
Re: Some questions
Now that all you people and companies out there are doing all these
common-lisp compilers, I'd like to ask you some questions:
Do you transform the source to continuation passing style before
How happy are you with this decision?
If you don't, do you do tail-recursion optimizations anyway?
If you do, do you do multiple values by calling the continuation with
Many of the Common Lisps floating around are based on Spice Lisp and
this compiler. Some exceptions are Symbolics, Lucid and KCL.
The current KCL compiler is a two-pass compiler which generates portable
C code. (I do not want to repeat the discussions on why C code and how it
is possible. Please refer to the KCL Report for this issue.) The main roles
of the first pass are:
1. to discriminate those lexical objects (variables, functions, blocks, and
tags) that are to be closed up in a closure from those not.
2. to collect optimization information such as type information and
Most of the compile-time error checking is done during the first pass.
The first pass generates intermediate tree code that is similar to the
original Lisp code but is scattered with the collected information all around.
The second pass is the main pass and is responsible for the rest of the
compilation job. Tail-recursive optimization is done during the second pass.
Many other optimization hackings take place also during the second pass.
KCL is not a descendant of any other Lisp. The only reference material we
had was the draft of CLtL during the development of the first running version
of KCL (October 1983 to March 1984). (CLtL itself was not yet published at
that time.) We wrote every line of the KCL code by ourselves. (There is one
exception: we later obtained the code of RATIONALIZE from the Spice project
and used that code without changes.) Thus KCL was oriented for Common Lisp
from the very beginning. In particular, the compiler supports many Common
Lisp features: The fact that the KCL compiler is a two-pass compiler already
indicates this. (We could make it a one-pass compiler if the lexical closure
were not supported by Common Lisp.) In addition, the compiler takes care of
keyword parameters for compile-time dispatching of such functions as MEMBER
and ASSOC. It also tries to avoid creation of lexical closures in such
situations as in MAP functions, FUNCALL, and APPLY. It tries to avoid making
a list for &REST parameters in some situations, etc, etc, etc.... But it is
true that there still remains big room for improvement.