I think it's time the experts on CL and Scheme sit down and do feasibility studies. I've seen attractive abstract arguments on both sides, but not so much that's concrete. Personally I'm biased toward elegant and minimal; I'd especially like to see more concrete information about CL to counteract that bias. Some questions I'd really like to know answers to: 1. Do the respective standards specify things (like behavior of text objects) that we would prefer to specify ourselves? (Neither camp has said anything about this AFAIK.) If so, this is harmful to ease of migration. 2. What constructs in one dialect would be difficult or impossible to implement efficiently in the other? (Michael Sperber _has_ given at least two potentially important concrete examples, efficient tail recursion and call/cc. Hrvoje Niksic and Martin Buchholz worry that an emulation of CL would be a "poor man's CL". This is important, but concrete examples of what they are afraid will be missing would be nice, so that we can check available emulations against them.) 3. Where will it be hard to emulate current elisp efficiently? 4. Where the semantics of common constructs differ among elisp, Common Lisp, and Scheme, how hard is it going to be for casual elisp programmers to make the switchover? How hard is it going to be for core developers and Lisp implementors to make the switchover? 5. Do we or CLisp or any of the suggested Scheme variants have an API that will allow us to separate the Lisp engine proper from extensions, like the C-level support for fontification? This is especially important if we hope to offload Lisp engine maintenance, as Bruno has offered to do for CLisp. mb> scheme is an interesting language, but ... mb> Scheme has been designed for programming language research, mb> rather than practical use. It has such a history of mb> minimalism that all scheme implementations had to provide mb> extensions to be useful. Hmm. Sounds like Common Lisp is going to require lots of extensions to be useful to us, to me. CLtL1, at least, makes no reference to editing buffers or multilingual text processing, frames or extents. Also, it seems possible to me that Common Lisp specifies some things we would rather be free to implement in our own way (doesn't CL specify the use of bucky bits and fonts in character representation, or did that go away?---I can't find the passage I'm sure I remember in CLtL1, sorry if this is misinformed). Minimal is good, if we want to support different extension languages. I don't know if that's a good idea in principle. I don't know if we can do it well, and almost certainly it won't get done well in a hurry. But it's an interesting idea. Minimal is good, if we are going to end up having to maintain the Lisp engine ourselves. Yes, Bruno says that he will help maintain a Common Lisp engine specific to XEmacs. Does he understand that that will possibly include things like C-level support for fontification? Do we or CLisp or any of the suggested Scheme variants have an API that will allow us to separate the Lisp engine proper from such extensions? I scanned CLtL1 again. "I am large. I contain multitudes." Or whatever old WW said. I think he had Perl in mind, though. mb> It still is missing many things. For example, my beloved mb> (when ...) is missing (from the standard). Hashtables are mb> missing. (when ...) is a trivial macro, isn't it? ("Very useful" and now "beloved"! What loyalty a trivial extension can engender!) Hashtables, we can do. Why would having these (and many similar items, I'm sure) _in the standard_ be useful to us? Why can't we do "the underlying engine will be Scheme, where extensions are desired Common-Lisp-compatible extensions will be preferred," as Michael has suggested is possible? mb> (call-with-current-continuation) is a very interesting mb> function, but one cannot expect ordinary humans to understand mb> it. It is only a tool for system implementors. XEmacs is a system, is it not? _We_ are system implementors. (Sorry for the implicit self-aggrandizement.) However, I will leave call/cc's serious usage to Michael and the Mark II version of Karl Hegbloom ;-) I imagine most package writers and so on will do so, too. If we can get coroutines and threads as cheaply as Michael suggests, that is a _big_ deal. I can stop running two (or more) XEmacsen and cutting and pasting URLs because of the damn blocking gethostbyname(). mb> The scheme community seems to be in a downturn. From casual mb> visits to the scheme repository, there seems to be little mb> progress in implementations or standardization. Hm? "Eye of the beholder," I guess. Dates on the most recent documents and source code seems recent enough. What does all the standardization associated with Common Lisp buy XEmacs? I understand that having a very powerful engine is a good thing, especially if it's standard. But what are the benefits to the editing or other core functionality of XEmacs? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091