Re: Preprocessor

Hrvoje> Raymond Toy <toy(a)rtp.ericsson.se&gt; writes: Hrvoje> Because it's highly questionable how useful Gcl is. Hrvoje> To be useful in short-term future, an elisp-to-C translator should not Hrvoje> try to reimplement XEmacs from scratch or to turn Elisp into Common Hrvoje> Lisp (or, for that matter, CLtL1). Hrvoje> My favorite strategy for elisp-to-C is the one (I think) originally Hrvoje> proposed by Kyle Jones some time ago: look at the opcodes that our Hrvoje> current compiler generates. Now look at the code in bytecode.c that Hrvoje> interprets it. A simple translator would simply take byte-compiled Hrvoje> code and translate it into C that looks like bytecode.c, but inlined Hrvoje> to directly *do* the stuff that P-code wants to do instead of Hrvoje> interpreting the P-code. Hrvoje> Although this looks simple-minded, I believe it would be a *huge* Hrvoje> speed win over the current virtual machine. This strategy has been used many times before. (In Gofer and MzScheme, to name two examples.) It has its benefits, but a significant speed gain is, perhaps surprisingly at first, usually not among them. (People tend to overestimate the time spent on syntax dispatch.) Of course, I may be underestimating the interpretive overhead in XEmacs, but I rather doubt it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla