LispOS compiler question

Matthias Hoelzl tc
Tue, 18 Nov 1997 04:12:29 +0100

Emergent Technologies <> writes:

> In an attempt to bring some life back into this group, I'll post a
> question. 

It is good to see that some others are still interested in LispOS 
as well.

> What would be a good compiler to use for writing a LispOS?  I think
> the following goals would be nice:
> 1.  Free

A good free compiler with supporting libraries (that can produce stand
alone applications) seems to be the main hindrance for getting free
Lisp based applications written.  So, yes, this would be a good thing
(even apart from the rest of LispOS).

> 2.  Fairly easy to hack (so the underlying lisp architecture can
> change).

This would be good, however I think that we need a possibility to
include optimization passes easily in the compiler. 

> 3.  Object code portable to Linux and Win32 (for bootstrapping
> reasons).

Agreed.  (However I think we need code portability to Linux and Win32
for more than just bootstrapping reasons.  If we don't have the
possibility to deploy applications developed on LispOS on other
platforms the whole project will be stillborn IMO.  I know that many
other posters on this list will violently disagree with me here.)

> 4.  Support proper tail recursion (not strictly necessary for Lisp,
> but required for Scheme).

I would welcome this, since I make heave use of recursion in my
programs, however this would somewhat complicate the compilation to C.

> I don't think it would be necessary to have a highly optimizing
> compiler.  

This is the point where I disagree.  I think we could start with a
simple compiler, since this would allow us to build up the
infrastructure for the project, but if we want LispOS to be
interesting we need to have a compiler with decent performance
sometime in the future.

> I think a simple compiler that output ANSI C in the Baker's
> explicit continuation passing style might fit the bill.

An ANSI C backend would be a very good thing to get the compiler
started and to keep it portable to new platforms, however I think
that some day we will need a native code back end for the most
common machines to build a comfortable interactive environment.
However this would be rather low on my priority list.

> What do others think?  Would anyone be able to take some spare time
> and write a wimp-ass compiler?

For reasons completely unrelated to the LispOS I have started to write
a compiler for a Scheme-like language two days ago.  At the moment the
only thing that exists is the reader which is closely modeled after
the Common Lisp Hyper Spec reader specification but written in Scheme.
It is not the most beautiful piece of software, but at least it is
able to read its own source, so it is good enough for my current
purposes.  I want to get the first version of the compiler working
before polishing individual parts.  If somebody wants to write a
compiler for the LispOS and is interested in the code I have, I will
gladly mail it to him/her.  The main reason for writing my compiler is
that I want to have a system where I can play around with some ideas
for meta object protocols and aspect oriented programming, so my
compiler will basically be very simple, with optimizations implemented
as aspect-programs and via compile-time MOPs.  Now, I don't expect
everybody interested in the LispOS to share my excitement about MOPs
and aspects, but I think that when programming a (simple) compiler for
the LispOS care should be taken to build it in a way so that advanced
optimizations and different backends can be plugged in without too
much hassle even if that complicates the task of designing the
internals of the compiler.  Otherwise we'll end up writing yet another
compiler when we come to the point where "real" applications are
developed on LispOS.

Unfortunately I don't have very much time to spend on my compiler at
the moment, so don't expect anything usable from me within the next
two or three months.  However I will gladly donate any parts that I
develop to a "LispOS compiler project" should it be formed.