ms> Many features aren't part of the Scheme standard because they can ms> be easily expressed within the language as it stands. True ms> concepts are more important, and here CL is weak. I could go on ms> about the virtues of hygienic macros, the evils of CL-style ms> macros, especially in connection with module systems, the ms> usefulness and beauty of call-with-current-continuation ms> etc. etc. etc. Someone make me. (Finger raised) I do. Especially about the module system. As far as I know, Scheme (even in RSR5) has no standarized module system (the package-system is a familiar thing for CL-programmers. AFAIK, standarized Scheme offers no such thing). What about OO ? I always wanted to start using CLOS (the Common Lisp Object System), but haven't had the urgent need to. But obviously, many current Elisp applications could probably benefit from _any_ OO Lisp extension. SJT> Re: global options and keyword arguments ms> However, Scheme idiomatics usually uses a parameterization ms> mechanism to achieve what you're talking about; they're similar ms> to a structured and thread-compatible version of dynamic binding. SJT> Urk. I mean, URL please. :-) Yes, I want to second that. In which way are "dynamic binding" and keyword arguments connected ? And is there a *standarized* way for keyword arguments in RSR[45] ? What I am after: this whole discussion about the benefits of Scheme and Common Lisp has been lead a thousands time. Why should we re-discuss very old arguments ? And, where is the _urgent_ need for replacing Emacs Lisp with either Scheme or Common Lisp that makes worth the work ? Sure, I would like to have a _real_ Common Lisp as the Lisp to program Emacs in (and that's why I have an eye on Erik Naggum's CL-Emacs project), but I am certainly not convinced that _replacing_ the current engine with anything else really offers any big gains. Say, we would replace the current engine with some (modified) foo-scheme implementation, like say guile, or the gtk-engine. Fine, now we can have some guys that already use that foo-Scheme implement some new bar-functionality. But what is the benefit for the current existing system ? And is it really true that replacing Emacs Lisp with another Lisp will encourage new users ? I doubt it, because, well, hey, here we have another lisp engine, that mainly consists of "Emacs Lisp" (note the quotes), because the _essential_ things for programming Emacs is _not_ the lisp language underneath but the functionality, and this is the real part which makes Emacs Lisp _Emacs_ Lisp (be it that the Lisp language is Elisp, Scheme, CL ...). And, I'm sorry to say that, but I always thought that the major difference between Emacs Lisp and both Scheme and Common Lisp is how binding works and that this is not a trival problem (i.e. translating Emacs Lisp binding to CL binding). But it's been a while since I looked inside that topic. If this is not a problem for some translator, please correct me and tell me why/how. ms> (Note that the reverse is not generally possible, since Common ms> Lisp is not properly tail-recursive and does not support control ms> abstraction.) AFAIK, tail-recursion is not required by the (ANSI) CL standard. Is it part of RSR(45) ? This would be very surprising news to me. SJT> But _we_ only care if those features would be useful to XEmacs SJT> running Scheme idioms emulated inside a Common Lisp substrate. SJT> No? I second that. Where is the beef ? SJT> Point is that a lot of the people who should contribute to this SJT> discussion don't even know where to start asking questions. I SJT> assume I'm not the only person totally ignorant of modern SJT> programming language theory on this list. Is that assumption SJT> unjustified? Nope, as far as I am concerned this assumption pretty much applies to me. 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