From: rob
Subject: public domain lisp availability ?
Date:
Message-ID: <105@innovus.UUCP>
As a rank beginner in the world of LISP, I am seeking a public domain (?)
version of a reasonably good COMMON LISP dialect with which to support
common lisp based backages.
This version should be easy to port, support, generate, reasonably compatible
with other COMMON LISP dialects, able to call C routines relatively easily,
and freely distributable in binary form.
We currently have the GNU distribution tapes with T and Scheme. How do these
rate ?? Any comments or suggestions would be appreciated.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rob Sciuk {Vanilla Disclaimer ...} {Not a flame ... merely a glimmer ...}
mail: Innovus Inc., 204-200 James St. S., Hamilton, Ont Canada L8P 3A9
uucp: ···@innovus, ..!utzoo!yunexus!maccs!innovus!rob
I am interested in writing a Lisp interpreter. This is mostly for the
educational experience, but I do have an application which would benefit
from a fairly stripped down version of Lisp.
Most of the textbooks and papers I consulted did not describe anything
beyond the traditional Lisp-in-Lisp. The few references I was able to
find on constructing Lisp systems were primarily pages and pages of
uncommented PDP-1 or Univac 1108 assembly code. These were less than
totally thrilling.
Since I want lexical scoping (although I don't necessarily need Scheme) a
byte-code compiler/interpreter combination seems to be the best way to go.
(This way I can just treat all local variable references as stack offsets
since I know the offsets at compile time. All I have to do to call a
function is to push the arguments on the stack and do a function call.)
I would greatly appreciate references to papers which describe how an byte-
coded interpreter and simple compiler are organized. Even better would be
a Lisp written in a high-level language (other than Lisp for obvious reasons).
I know this stuff exists, I just don't know where to look for it. I've check
out numerous programming language survey books, the source for Berkeley Franz,
Gnu Emacs' mock-Lisp, X-Lisp etc, but I haven't found a good reference to an
implementation guide yet. Surely there are tech reports from the late sixties
or early seventies which deal with this sort of thing?
Jonathan A. Chandross
Internet: ···@paul.rutgers.edu
Uucp: ···········@paul.rutgers.edu
From: Richard Fritzson
Subject: Re: Information on Lisp Interpreters/Compilers
Date:
Message-ID: <9288@burdvax.PRC.Unisys.COM>
In article <·························@paul.rutgers.edu>, ···@paul (J. A. Chandross) writes:
>I am interested in writing a Lisp interpreter.
>
>I would greatly appreciate references to papers which describe how an byte-
>coded interpreter and simple compiler are organized. Even better would be
>a Lisp written in a high-level language (other than Lisp for obvious reasons).
>
>I know this stuff exists, I just don't know where to look for it. I've check
>out numerous programming language survey books, the source for Berkeley Franz,
>Gnu Emacs' mock-Lisp, X-Lisp etc, but I haven't found a good reference to an
>implementation guide yet. Surely there are tech reports from the late sixties
>or early seventies which deal with this sort of thing?
>
I don't think its obvious why you don't want a Lisp written in Lisp.
About ten years ago I implemented a lexically scoped Lisp and based it
primarily on the Steele and Sussman MIT tech reports entitled "The Art
of the Interpreter or, The Modularity Complex (Parts Zero, One, and
Two)" and the LAMBDA series of reports and the reports on the early
SCHEME chips. (all late seventies reports)
The style of programming they adhered to in these documents made it
possible to move from the Lisp code to any other programming language.
They did not, for example, implement recursion by using recursion; it
was done explicitly, with stacks.
I don't believe that material was turned into a book. But some of it,
I think, and many of the ideas, wound up in the textbook "The
Structure and Interpretation of Computer Programs" by Abelson and
Sussman.
If you want the tech reports and can't find them just from my vague
allusions, write to me and I'll send you the exact references.
-Rich Fritzson
-Rich Fritzson
INTERNET: ········@prc.unisys.com
UUCP: {sdcrdcf,psuvax1,cbmvax}!burdvax!fritzson
From: Skip Egdorf
Subject: Re: Information on Lisp Interpreters/Compilers
Date:
Message-ID: <23563@beta.lanl.gov>
In article <·························@paul.rutgers.edu>, ···@paul.rutgers.edu (J. A. Chandross) writes:
> I am interested in writing a Lisp interpreter. This is mostly for the
> educational experience, but I do have an application which would benefit
> from a fairly stripped down version of Lisp.
> ...
>
> Jonathan A. Chandross
> Internet: ···@paul.rutgers.edu
> Uucp: ···········@paul.rutgers.edu
Try to find a copy of
Anatomy of Lisp
John Allen
McGraw-Hill 1978
ISBN 0-07-001115-X
Even though it pre-dates common lisp, it contains information
on implementation strategies for the differently scoped kinds of lisps,
garbage collectors, and everything else needed to implement any
sort of Lisp you wish within reason.
The book is hard to get into at first because the author introduces
a very formal notation for lisp in order to seperate the syntax from
any pre-conceived semantics (I think...). If you hang in there, you
will be rewarded with a very good understanding of the internals of
Lisp. As in any field, advances have been made in Lisp technology
in the last ten years. You should find Allen's book a good basis
for getting into more current papers regarding Lisp implementations.
The only other alogrithmic help you might need is the reader, where
I reccommend Steele's book. The chapter on the reader is enough to allow
one to construct a lisp reader from scratch. (Well, I got one working
doing nothing more than following the book.)
I did the same as you suggest a few years ago; Try to write a simple
Lisp just for the fun of it (in my case). With Allen's and Steele's
books, I found the job both do-able and enjoyable. Everyone needs a hobby
I guess. Let us (the net) know how you do.
Skip Egdorf
···@lanl.gov