On Sun, Feb 10, 2008 at 01:32:49AM -0800, Andrew Lentvorski wrote:
For example, *every single compilers course and book* covers parsing and lexing. The Lisp folks simply bypass that section of understanding by snarfing it from the underlying environment. It's *beneath* them to cover something so terribly mundane. Well, excuse me, but then people are going to turn to the course or book that *does* explain that. You can't just cover what you *want*; you have to cover what the student *needs*. Similar things hold for continuations or macros--"Well, those are too hard so were just going to use those from the implementation Lisp". ARGGGGHHHH!
Most lisp systems implement the reader right in lisp. Common lisp effectively requires it, since the reader is extensible. I think there is a lot to learn from the reader of common lisp, since it shows how a parser can be written in an extensible way. A lot is just that it isn't a very difficult language to parse. Parsing non-lisp languages in lisp is generally easier than parsing them in code written in another language. Symbolic processing is something lisp is good at. People generally implement the language they are writing for in that language. If anything, it helps you make sure that you've done things right. BTW, ECL (Embeddable Common Lisp) implements a full common lisp bytecode compiler and interpreter in C. The compiler is only about 2500 lines long (but it's hard to say how much of the rest of the runtime counts). They use this so they can bootstrap their native code compiler without needing another lisp system. David -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
