jac@paul.rutgers.edu (J. A. Chandross) (02/17/89)
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: jac@paul.rutgers.edu Uucp: rutgers!jac@paul.rutgers.edu
fritzson@prc.unisys.com (Richard Fritzson) (02/17/89)
In article <Feb.16.21.20.13.1989.8344@paul.rutgers.edu>, jac@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: fritzson@prc.unisys.com UUCP: {sdcrdcf,psuvax1,cbmvax}!burdvax!fritzson
hwe@beta.lanl.gov (Skip Egdorf) (02/18/89)
In article <Feb.16.21.20.13.1989.8344@paul.rutgers.edu>, jac@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: jac@paul.rutgers.edu > Uucp: rutgers!jac@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 hwe@lanl.gov