A lot of the traffic on this newsgroup centers around ANSI Common Lisp, that is, interpreting the language specification, or how to go about using the language. Would it be on-topic to ask questions about how Common Lisp could be implemented? I'm currently looking into writing a Lisp front-end to GCC, and I'm getting to the point where I'd like to ask questions about How Things Are Done. If this isn't an appropriate forum for such a discussion, can you suggest something where talk of implementing a Lisp run-time and compiler from scratch would be on-topic? (Perhaps comp.compilers is more appropriate, but I think I'm looking for something more specific.)
(I believe it was Craig Burley who pointed out the fact that GCC doesn't currently support any functional programming languages. I find that interesting, considering RMS's background.)
-- Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16 Pope, Patron Saint of All Things Plastic fnord, and Salted Litter of r.g.s.b "When I was a kid, I used to think that Dammit was God's last name, just like Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d
In article <w4or9qrju8t....@nemesis.irtnog.org>, His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated <xenop...@irtnog.org> wrote:
>A lot of the traffic on this newsgroup centers around ANSI Common >Lisp, that is, interpreting the language specification, or how to go >about using the language. Would it be on-topic to ask questions about >how Common Lisp could be implemented?
Practically anything about Lisp is on-topic. There are a few specific areas where there are more appropriate groups (e.g. you'll get better answers about Emacs Lisp in the Emacs newsgroups, and about Autolisp in the CAD newsgroup), but just about everything else is fine here.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <xenop...@irtnog.org> writes:
> A lot of the traffic on this newsgroup centers around ANSI Common > Lisp, that is, interpreting the language specification, or how to go > about using the language. Would it be on-topic to ask questions about > how Common Lisp could be implemented?
Assuming this is a serious query, despite the "I'm desperate for attention!" user name...
I think that this is a reasonable newsgroup for questions about implementation strategy of any Lisp. I don't know of any more specific newsgroup.
I suggest you look at the CMU Common Lisp sources, available under "http://www.cons.org/cmucl/". There you will find a complete public-domain implementation of CL, implemented in CL itself. The compiler is designed for maximum efficiency and is pretty hairy -- not the best thing for a beginner to learn from, perhaps -- but the code is mostly of good quality and pretty readable.
Good luck, Scott
=========================================================================== Scott E. Fahlman Internet: s...@cs.cmu.edu Principal Research Scientist Phone: 412 268-2575 Department of Computer Science Fax: 412 268-5576 Carnegie Mellon University Latitude: 40:26:46 N 5000 Forbes Avenue Longitude: 79:56:55 W Pittsburgh, PA 15213 Mood: :-) ===========================================================================
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <xenop...@irtnog.org> writes:
> A lot of the traffic on this newsgroup centers around ANSI Common > Lisp, that is, interpreting the language specification, or how to go > about using the language. Would it be on-topic to ask questions about > how Common Lisp could be implemented? I'm currently looking into
sure
> writing a Lisp front-end to GCC, and I'm getting to the point where > I'd like to ask questions about How Things Are Done. If this isn't an > appropriate forum for such a discussion, can you suggest something > where talk of implementing a Lisp run-time and compiler from scratch > would be on-topic? (Perhaps comp.compilers is more appropriate, but I > think I'm looking for something more specific.)
I think you will find Common Lisp (I assume that's the dialect you're aiming for, unless ISLisp is a more reachable goal?) is not all that different from more mainstream languages with respect to compiling techniques. You have a very well specified lexer/parser in the reader that is also available for the users. It is block structured with mostly lexical scoping. There are two well known methods for implementing dynamic scoping (deep/shallow). CL may not look it but it is a fairly small language with a big library. You can start with a small kernel, use that for bootstrapping the reader and macroprocessing and you can write the thing in itself. This may make it hard to build from scratch (witness CMUCL).
A few references: Lisp in easy pieces -- Queinnec Compilation with continuations -- Appel (This is about compiling ML but some ideas apply) Garbage Collection -- Jones & Lins
More on the Scheme side you can find Steele's thesis on his Rabbit compiler with source at MIT and Kent Dybvig's thesis about three implementation models is also online.
Sorry to be a bit vague but I don't have exact references around right now. Mail me if you can't find things.
> (I believe it was Craig Burley who pointed out the fact that GCC > doesn't currently support any functional programming languages. I > find that interesting, considering RMS's background.)
>>>>> "SF" == Scott Fahlman <s...@cs.cmu.edu> writes:
SF> Assuming this is a serious query, despite the "I'm desperate SF> for attention!" user name...
You know, I get a lot of grief from the handle. One guy went so far as to flame me because of it on the EGCS mailing list (even though I was on topics, etc.)
SF> I suggest you look at the CMU Common Lisp sources, available SF> under "http://www.cons.org/cmucl/". There you will find a SF> complete public-domain implementation of CL, implemented in CL SF> itself.
A great deal of my difficulties in trying to figure out how to implement Common Lisp is due to the fact that so many example implementations are written in Lisp. I'm trying to implement a compiler and run-time in C, if only because that is the language GCC is written in, and I'm running into a variant on "which came first" each time I see a Lisp facility described.
It is very frustrating because I cannot nail down a subset of Common Lisp to implement. With C, I have a fairly clear division between the C language and the C standard library. With Lisp, so much of the language *is* the standard library that it makes identifying primitives very difficult.
(Of course, I could be making this way too hard or misunderstanding something fundamental, which is why I asked whether it is OK to post the I'm-writing-an-implementation-type questions on this newsgroup.)
-- Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16 Pope, Patron Saint of All Things Plastic fnord, and Salted Litter of r.g.s.b In a lecture, Werner von Braun once said "Ve haf alvays been aiming for zer stars" and a little voice at the back replied "But ve keep hittink London".
>>>>> "ecm" == Eric Marsden <emars...@mail.dotcom.fr> writes:
ecm> The proper way to interface GNU CC to a new language front ecm> end is with the "tree" data structure. There is no manual ecm> for this data structure, but it is described in the files ecm> `tree.h' and `tree.def'.
I'm aware of this. The EGCS people pointed out the tree interface as soon as I mentioned "add a front end". The fellow who maintains GPC was also kind enough to point out the documentation included in GPC in regards to interfacing to the code generator.
ecm> They automatically benefit from all optimizations and new ecm> hardware ports add to the gcc backends.
Yup. "I don't have to do it" is why I decided to try to add to GCC. :)
ecm> * as Sam Steingold suggested, starting from CLISP bytecode ecm> would save a lot of work. There are a quite a lot of ecm> operators in the CLISP virtual machine, but basically it is a ecm> stack architecture.
But then it wouldn't really be a Lisp compiler. It'd be a glorified assembler. I really want to go and implement a full-grown Lisp compiler, mainly because I have some ideas on making foreign function support nice and easy, etc.
-- Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16 Pope, Patron Saint of All Things Plastic fnord, and Salted Litter of r.g.s.b In a lecture, Werner von Braun once said "Ve haf alvays been aiming for zer stars" and a little voice at the back replied "But ve keep hittink London".
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <xenop...@irtnog.org> writes:
> A great deal of my difficulties in trying to figure out how to > implement Common Lisp is due to the fact that so many example > implementations are written in Lisp. I'm trying to implement a > compiler and run-time in C, if only because that is the language GCC > is written in, and I'm running into a variant on "which came first" > each time I see a Lisp facility described.
ISTR that "ANSI Common Lisp" (Paul Graham, ISBN 0133708756) contains a chapter/appendix that implements Lisp in Lisp, with a description of what the necessary primitives are. Might be a starting point...
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <xenop...@irtnog.org> writes:
> C language and the C standard library. With Lisp, so much of the > language *is* the standard library that it makes identifying > primitives very difficult.
Why not just implement the special forms and the system classes? They're plainly identified in the specification, and they're not much of the language. I just don't see the problem.
If you're working from some other document than the language specification, that's probably your problem.
"Fernando D. Mato Mira" <matom...@iname.com> writes:
> Raymond Wiker wrote:
> > ISTR that "ANSI Common Lisp" (Paul Graham, ISBN 0133708756)
> Is this book interesting if you already know CL?
I'd expect that Graham's other title ("On Lisp") would be more interesting in that case :-)
> Are the differences between ANSI and CLTL2 highlighted > more clearly than elsewhere?
I don't think there was anything specifically about this in the book. On the other hand, the Common Lisp HyperSpec has the details about ANSI CL, which I guess is what you actually want (are there any implementations that are specifically CLTL2?)
Raymond Wiker wrote: > "Fernando D. Mato Mira" <matom...@iname.com> writes:
> > Raymond Wiker wrote:
> > > ISTR that "ANSI Common Lisp" (Paul Graham, ISBN 0133708756)
> > Is this book interesting if you already know CL?
> I'd expect that Graham's other title ("On Lisp") would be more > interesting in that case :-)
But I've already read it years ago and it's fantastic. That's why I was wondering about it..
> the book. On the other hand, the Common Lisp HyperSpec has the details > about ANSI CL, which I guess is what you actually want (are there any > implementations that are specifically CLTL2?)
The old version of Lispworks I own is. But it's mainly an issue of keeping myself up to date (low priority, I've got some more interesting reading to do).
-- Fernando D. Mato Mira Real-Time SW Eng & Networking Advanced Systems Engineering Division CSEM Jaquet-Droz 1 email: matomira AT acm DOT org CH-2007 Neuchatel tel: +41 (32) 720-5157 Switzerland FAX: +41 (32) 720-5720
On 16 Mar 1999 12:15:10 -0500, His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated <xenop...@irtnog.org> posted:
>A great deal of my difficulties in trying to figure out how to >implement Common Lisp is due to the fact that so many example >implementations are written in Lisp. I'm trying to implement a >compiler and run-time in C, if only because that is the language GCC >is written in, and I'm running into a variant on "which came first" >each time I see a Lisp facility described.
It might be useful to take a *little* bit of time and look at how the FORTH community has tackled this; FORTH systems have traditionally been written in FORTH.
They wind up taking some minimal number of "code words," constructing the rest of the operators using those words (a "word" is an operator), and then using something called a target compiler to build a fresh environment that can then be used as a full environment.
-- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html> cbbro...@hex.net - "What have you contributed to free software today?..."
> A great deal of my difficulties in trying to figure out how to > implement Common Lisp is due to the fact that so many example > implementations are written in Lisp. I'm trying to implement a > compiler and run-time in C, if only because that is the language GCC > is written in, and I'm running into a variant on "which came first" > each time I see a Lisp facility described.
> It is very frustrating because I cannot nail down a subset of Common > Lisp to implement. With C, I have a fairly clear division between the > C language and the C standard library. With Lisp, so much of the > language *is* the standard library that it makes identifying > primitives very difficult.
> (Of course, I could be making this way too hard or misunderstanding > something fundamental, which is why I asked whether it is OK to post > the I'm-writing-an-implementation-type questions on this newsgroup.)
Eclipse (see http://www.elwood.com/eclipse-info) started out as a C library written in C (because the things I needed to interface to were in C). By the time the first version was done, I figured it would be a lot easier to: 1. Write everything in Lisp (because after, all it's easier to write things in Lisp). 2. Implement (pretty darn close) to the full ANSI spec (because there wasn't too much that didn't turn out to be useful in defining something else). (Perhaps I went a little overboard in defining much of the system in terms of CLOS and not the other way around, but bootstrapping aside, it really was easier.) (Later versions were truly ANSI and the germ of the eventual product.)
I expect that countless Lisp implementations in the last 40 years have followed that pattern. I guess it's a truism which you never really believe when someone tells you its true, and that you just have to experience yourself by doing both exercises yourself (i.e. small Lisp in some other langauage vs. big Lisp in Lisp).
Howard R. Stearns wrote: > .... > I expect that countless Lisp implementations in the last 40 years have > followed that pattern. I guess it's a truism which you never really > believe when someone tells you its true, and that you just have to > experience yourself by doing both exercises yourself (i.e. small Lisp in > some other langauage vs. big Lisp in Lisp).
For sure, Lisp is the best language for writing a compiler, if ever there was a "symbolic" processing task, this is it.
My approach is whatever can't be in Lisp is best written in assembly language, and the compiler should generate this same assembly. Then one must only write a simple assembler to port to another low-level instruction set. If the assembler/compiler assumes a common register model that is "portable", this makes for a VERY portable and relatively high-performance implementation.
My next personal technical challenge is to have the GC written in Lisp instead of C or assembly, which will be done for the OODB.
>>>>> "KMP" == Kent M Pitman <pit...@world.std.com> writes:
KMP> Why not just implement the special forms and the system KMP> classes? They're plainly identified in the specification, and KMP> they're not much of the language. I just don't see the KMP> problem.
Because while I am working from the HyperSpec (and have been since the beginning), I did not identify the first five chapters as being "the core" of Lisp, especially since core-type things like iteration and whatnot (things that I would consider being "part of a language") are described in later chapters.
But yes, now that I'm looking at them in that light, those operations are pretty much all I need to put a working implementation together. Duh. I don't know why I didn't realize that sooner. :-/
-- Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16 Pope, Patron Saint of All Things Plastic fnord, and Salted Litter of r.g.s.b In a lecture, Werner von Braun once said "Ve haf alvays been aiming for zer stars" and a little voice at the back replied "But ve keep hittink London".
On Tue, 16 Mar 1999, "His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" wrote: >>>>>> "SF" == Scott Fahlman <s...@cs.cmu.edu> writes: >A great deal of my difficulties in trying to figure out how to >implement Common Lisp is due to the fact that so many example >implementations are written in Lisp. I'm trying to implement a >compiler and run-time in C, if only because that is the language GCC >is written in, and I'm running into a variant on "which came first" >each time I see a Lisp facility described.
Why don't you look at EuLisp (there are links to it in the ALU)? It is close to CL and there the language is layered in the sense that there's a minimal subset which is a Schemeish lisp with objects and generic methods, plus additions that constitute the MOP. If not as a language to implement, you might find it more clear in the spec what is essential and what is not.
