I was planning to just lurk during this discussion, but since my name actually got mentioned, I guess I should give an opinion. Ill give a thesis statement first so people can just delete the message if they violently disagree. Common Lisp is a better language for managing software engineering projects than scheme. First let me say that I like scheme a lot and it would be cool to have a scheme engine available in XEmacs so that I would get a chance to hack scheme. But I don't think that cool is a good enough reason for attempting the huge job of evolving the codebase to another language. The questions always are the wins in doing it, and how hard will it be. There are several arguments for common lisp. Emacs-lisp is a maclisp variant and common lisp is designed with the explicit intent to easily migrate maclisp programs to common lisp. The let argument that people were mentioning earlier does not really exist because all globals are treated as special variables and will be shadowed by a let just like it happens in elisp now. Second common-lisp has structures, objects, and generic functions so that you can generalize a lot of common code that is probably laying around. Packages give you namespace separation so that you can worry less about name clashes and having to have lots of conventions to avoid these clashes. Third common lisp has the #+ and #- feature reader macros which allow you to take advantage of features that may or may not be available in the compiled XEmacs system on a particular platform like minimal tagbits or CDE. Fourth and probably most important, common lisp has powerful exceptions which are CLOS objects and powerful exception handling semantics which will allow better handling of exceptional situations have the potential to make the system very robust. None of these things are available in standard scheme, and this to me is what separates a language designed for properly engineering a complex system like XEmacs has become. The perfect example, to me is scheme48. Look at the things that were added to the system to make it usable from an engineering standpoint and note that its non-standard scheme. So although you may hurt yourself and others trying to lift the common lisp standard. That same standard provides all of the things you need to evolve elisp to common lisp and make it more manageable and robust from an engineering standpoint and will allow future designs to be a lot cleaner if you can take advantage of CLOS. -Reggie