Hrvoje> Well, there are reasons such as size, speed, efficiency etc. And there's maintainability. Hrvoje> The Scheme users and implementors don't have the constraint Hrvoje> of previous implementation of Common Lisp idioms. We do, Hrvoje> and I would like us to preserve them. Hrvoje> If we choose Scheme, I don't see the point. The main idea to programming in Lisp-like languages has always been that you tailor the programming idioms you use to the problem at hand, and implement them using macros and higher-order functions. Essentially, you embed your own "little language" into Lisp. If there's any one Lisp programming idiom, that's it. This doesn't happen much in Emacs Lisp because the language is not expressive enough. It happens all the time in Common Lisp as well as in Scheme. Scheme 48 comes with an embedded version of Icon and one of Dylan. scsh comes with an embedded version of awk. MzScheme comes with essentially an embedded version of Java etc. etc. etc. This all makes perfect sense. I'm quite sure similar things exist in CL implementations. (The CL *standard* specifies embeddings of Standard Lisp, Franz Lisp, Lisp 1.5, Fortran, ..., ...) Hrvoje> I don't like CMU CL (far too slow and buggy IMHO), Hrvoje> Exactly. And it's almost impossible to compile. And it's fucking Hrvoje> huge. Etc. I didn't mean to advocate it too much. CMU CL occasionally shows up in language benchmarks, and does pretty well there. If and when it works ... Hrvoje> Clisp doesn't have a native compiler, but it would Hrvoje> probably serve our purposes much better. Totally. Hrvoje> P.S. Hrvoje> I'll forward my exchange with Bruno to the list. Great! -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla