Hrvoje> I think both [CL and Scheme] specify characters as Hrvoje> strings, as you surely guessed. Huh? Elisp does not. Characters are a separate type. Again, what kind of strings? Mule requires MBCs or widechars, the current Mule requires MBC, but several of us would prefer widechar. Another example: I just recalled from CLtL1 that (eq ?a ?a) need not be true (for efficiency reasons, they might be implemented as immediate operands in some machine languages). If this is still true under Standard CL, we have to rip out any such comparisons of characters. Ebola mutates and lives.... The point is that we have to check _all_ of those nits if we really want a standard-conformant Common Lisp as our substrate, and there are going to be thousands of nits in Common Lisp. I don't really want to deal with a Lisp in which setting the package to elisp makes a change in the behavior of eq, or an XEmacs in which setting the package to _other_ than elisp enforces such a change. And if there are many of them.... Of course, if you want to standardize on an implementation, such as Clisp, then you can use that as the reference. If you're lucky, (eq ?a ?a) and other such properties of ELisp will be guaranteed to be true. Except that programs that use that kind of knowledge are not standard Common Lisp any more, and there's no guarantee that the implementation won't change, leaving us with the maintenance of the Lisp engine that works our way. I'm not saying that these are actual problems. I don't have the knowledge of CL or Scheme to say they are or aren't. However, such problems _could_ exist, and I'm just asking for assurances that they don't, or if they do they won't affect separate maintainership, and some idea of how they would be worked around if they do show up. Hrvoje> Why is this an issue? I don't *want* to implement Scheme Hrvoje> in CL, nor do I want to implement CL in Scheme. Hrvoje> Can you name some of these people? What exactly do they Hrvoje> want to achieve by implementing CL in Scheme, or vice Hrvoje> versa? (1) Michael Sperber. (2) Keeping CL proponents happy if the engine turns out to be Scheme, among other things. Hrvoje> And what does that have to do with what we are Hrvoje> discussing here (extension language for XEmacs)? Supporting multiple dialects of extension language. Which we already know you don't like. That doesn't mean nobody likes it. More important, it doesn't mean that that won't be reached as a compromise solution. Hrvoje> I have no idea what you mean here. I haven't "taken Hrvoje> advantage" of you. You noticed that Bruno should maintain Hrvoje> font-lock.c, and I said he shouldn't. I see no reason in Hrvoje> this world why clisp maintainer should maintain XEmacs Hrvoje> code. I don't either, and the fact that you answer by implying I think he should is what I mean by legalistic. You're avoiding answering the question of the dis/advantages of CLisp by pointing out my ignorance of what is part of the Lisp engine proper and what is not. Hrvoje> That would be the whole point of the move. I know that, and you know that I know, I hope. Now explain why you have _confidence_ that something as large and standard-ridden as CLisp is going to be a satisfactory substrate for XEmacs. Having done that, explain why you have confidence it is going to stay _both_ satisfactory and separately-maintained. Hrvoje> Huh? We only have to extend it, not maintain it. You're right. (But see above regarding implementation details of things like characters and eq.) However, we do have to maintain any XEmacs-specific extensions, and one of the disadvantages of the small Scheme engine is that those extensions are likely to be many and large. One of the advantages of the small Scheme engine is that the engine itself is more likely IMO to remain separately-maintainable than a large CL engine which will probably (IMO, again) need many small XEmacs-specific changes as time goes on. Hrvoje> I'm afraid we can't. Hrvoje> Bruno does that already, or whoever maintains the Lisp Hrvoje> substrate. And when "whoever" turns out to be "XEmacs Development Team"? All I have as evidence that it won't is your opinion (and Erik Naggum's opinion supports you). All anybody else in this thread has committed to so far is that it will be easier for programmers to migrate to CL. Michael is on speaking terms with Scheme, and its implementations. Better the 9th-level fire elemental you know.... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091