On Wed, Mar 07, 2007 at 11:13:47AM +0100, Pascal Costanza wrote: > The terms "compiler" and "interpreter" are not well-defined. But > AFAICT, a compiler typically works in two phases: A translation from > one representation to another one, where the latter is typically a > representation that can be executed by some interpreter (for example, > a CPU). > > An interpreter typically works in one phase: It evaluates expressions > one by one without doing any sort of whole-program analysis.
I think such a distinction is bogus: _all_ implementations of a language do _some_ processing to convert the program from its external representation to something that can be executed. There's only a difference in how complex this processing is. In particular, simply calling (read) already performs lexical and syntactic analysis on the input and transforms the program into an abstract syntax tree. This, I'd say, is already very, very primitive compilation. A "pure interpreter" would treat the program as a blob of text throughout the execution. A ghastly number of implementations for various string-based scripting languages actually do this, but I don't think there are any for Scheme. That being said, I'll pitch in my $.02... The first Scheme implementation whose internals I studied was Guile. It is nominally a branch of SCM, but I don't know how much in common they had then (or have now, nine years later). But I do recall that the "interpreter" -flavour of the implementation made macros (and the evaluator in general) exceedingly hard to understand. Macros were represented as procedures that didn't evaluate their arguments, and whose return values were cached so that each expansion happened only once. So Guile was in effect still living in the pre-80's FEXPR- and MACRO-ridden Lisp world. First encountering such an implementation seriously hindered my understanding of how Scheme's syntax works, and I still cannot think of any redeeming value for such an approach. It certainly didn't make Guile's internals any simpler. So I don't see a compelling reason why R6RS should go out of its way to support implementations with such an approach. Lauri _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
