Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber Hrvoje> [Mr. Preprocessor]) writes: Lots of elisp code can run under Hrvoje> Common Lisp almost unchanged. This is not true for Scheme. Hrvoje> Not so by design. In fact, we were discussing introduction Hrvoje> of a lexically scoped `let' to elisp many times. And guess Hrvoje> what? The proposed semantics were equivalent to those used Hrvoje> by CL -- lexical scope by default, dynamic scope for special Hrvoje> variables. Excuse me, Hrovje, where is this an argument for "not so by design" ? We're arguing about probably having to change a lot of _existing_ Emacs Lisp code and not about the introduction of a new `lex-let'. Hrvoje> Quite true -- I am not denying this. Hrvoje> I believe clisp is small enough, especially if we remove the Hrvoje> parts we don't need. Hrvoje> I don't care. Emacs is not ANSI CL. If that was the Hrvoje> impression I was giving, I apologize, because that is not Hrvoje> what I meant. But, what is then the point of substituting Emacs Lisp with another non-sense Lisp ? I don't get it. If we substitute Emacs Lisp with something else, I would like to have an ANSI CL system (preferred) or a state-of-the-art RSR5-Scheme system. And, my favourite, if somebody wants to replace the existing lisp engine, go for a language engine that allows support for Emacs-Lisp, Common Lisp and Scheme (and perl or tcl, perhaps). Is here somebody how followed the discussions on the Lisp-OS/VM-Mailing Lists ? All arguments which came up here have been discussed there already. With the following results: those who liked Scheme, went to do some stuff in Scheme. And those, who wanted a CL system, used CL. Guess what: I have not seen coming anything useful out of the efforts. Hrvoje> a clear idea of what it would take. This, however, should Hrvoje> not mean I get no vote in the discussion. I know where I Hrvoje> want to end up. Please, say so, loud and clearly. I just said where I would like to end up: with a Lisp engine supporting any flavour. Hrvoje> I don't like CMU CL (far too slow and buggy IMHO), and I Hrvoje> haven't worked with GCL much. It might be usable. If you really think CMUCL is too slow and too buggy, you won't want to consider GCL. (BTW: I haven't used CMUCL 18a, only the old 17f version. On Linux, this old version certainly was slow [no high speed garbage collection] and contained some bugs [especially the ffi], but I never encountered any bugs on a grown-old 17f on Sun Systems. Note that currently most development on CMUCL seems to be done on Intel systems, so the situation is much likely to change [or has already improved]. With clisp I had had problems in the past of even compiling it under Linux.) Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- Why people hate using Lisp: "Are people suffering from parenthophobia-by-proxy, mistaking `parens' for `parents'?" - Erik Naggum in comp.emacs.xemacs