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? Hrvoje> I've never read his messages that way, except in Hrvoje> theoretical terms ("CL *can* be implemented in Scheme.") Hrvoje> Do you know something that I don't? I didn't mean that he lusts for a CL implementation in Scheme, simply that he recognizes that some level of CL compatibility is going to be necessary, and that's fine with him. Michael, stomp me if I've misrepresented you, please. Hrvoje> I don't think Scheme will ever satisfy CL proponents. Happy != satisfied. It probably wouldn't be too far off the mark to replace "happy" here with "not talking about development splits", for my purposes. Hrvoje> And what does that have to do with what we are discussing Hrvoje> here (extension language for XEmacs)? Hrvoje> More important, it doesn't mean that the development won't Hrvoje> split. Extremely important. Hrvoje> Multiple extension languages sounds like big Hrvoje> trouble. What do you think "elisp:foo-n", n goes from 1 to 1000, is, if all the foo-n are defined in base Common Lisp too, but differently? Obviously, I think that that is the same problem as multiple extension languages, of perhaps somewhat lesser degree. I take it you think it is not a problem (most likely because you believe n is small)? If we make "old ELisp" available as an option, who's going to police the contributors who continue to use it? Not me. And there are some people who find the prospect exciting. (Not me, but there have been a couple of comments to that effect. Holger Schauer, for example; dunno how serious he is.) Hrvoje> I definitely thought it was what you meant. I'm sorry, I'll be more careful. Hrvoje> And you are insulting me by putting intentions in my mouth Hrvoje> that I never had. I don't accuse you of insulting me when you do the same thing. I prefer to think of it as a misunderstanding. I don't think you have evil intentions, but my straw-man examples are getting dissected while my real questions aren't getting answered. Hrvoje> I had explained the technical merits of clisp before on Hrvoje> this list (I have forwarded some of Bruno's mails), and so Hrvoje> did others (Reginald Perry, for one.) I've read them. Many two or three times. They don't answer my questions (possibly because of my own ignorance). Perry's comments on use of exceptions and objects in large software projects ring true, but those advantages will be part of Michael's "long slow migration" (I may be overdoing that) to using the new native Lisp. As slow as that's going to be, it could theoretically wait on improvements in the Scheme modules: If call/cc is good for anything, it had better be good for exception handling ;-) And Michael mentioned a TinyCLOS in Scheme for objects and exceptions. Bruno does not seem to be an expert on XEmacs internals. And he has committed to extensions needed by XEmacs, not to implementation changes needed by XEmacs. Can you assert that there are none of the latter? Will Bruno go so far as to change internals of CLisp to fit XEmacs needs? Also, to clarify two points, note that I don't consider ease of migration for programmers a _technical_ merit. It's not clear to me how you feel about that. Second, the technical merits of CLisp itself are not my issue here; I'm concerned about the technical merits and demerits of trying to interface a CLisp (or other Common Lisp) substrate to XEmacs. And likewise Scheme, of course. Hrvoje> If enough work is done on ensuring it is, I don't see why Hrvoje> [CLisp] wouldn't be a good choice [as a substrate for Hrvoje> XEmacs]. "Enough work" can be one hell of a lot of work. Hrvoje> Define "confidence." The _definition_ of confidence is a written proposal with a schedule (cf. Fred Brooks, Ed Yourdon, Watts Humphrey, ad nauseum). I have no thought of _asking_ anyone for that. But one of the attractions of Scheme for me is that Michael is already moving in the direction of a written proposal, and has written some code related to such a project. That gives me some confidence that a Scheme implementation will happen, with few defects, in a timely fashion, with its necessary documentation, if it gets a green light. What I'd like to see is a list of (potential) problems and how we're going to deal with them, or why they're not really problems.[1] On the CLisp side, the only persons who answered any of my specific technical questions are not (explicitly, at least) CL proponents: Michael and Jerry James. Everybody else is saying "I'm sure we can make CL work" and "I like CL better and so will everybody else." The latter is important, but not technical.[2] The former is, precisely speaking, vaporware. Hrvoje> Because otherwise the whole thing would make no sense. If Hrvoje> this goal cannot be met with clisp, then clisp is not the Hrvoje> right choice. So tell us how we're going to meet the goal. I don't doubt your desire or willingness to work and to help coordinate with the CLisp project. However, the devil is in the details, and the smaller and more invisible the detail the nastier the devil. Details are both an advantage and disadvantage. If the many details of CLisp are mostly right, and the remainder can be fixed without maintaining it ourselves, advantage CLisp. If the wrong details are many and the separate maintainer is unwilling to fix them, advantage Scheme---any Scheme, _because_ it doesn't specify many details. Consider: if you personally _want_ to wrestle with the details of implementation of a CLisp substrate for a while, cool. But if you want to keep on doing the stuff you've been doing, and not spend humongous time on Lisp engine details.... You're the obvious candidate that participants in this discussion will look to for managing the clean up if anything does go wrong with a CL engine, don't you think? If not you, then who? We don't have a volunteer yet; if there are problems, they're definitely not Bruno's problems, although he clearly has strong sympathy for XEmacs. And that word "managing": a failure could require a lot of cooperative work to get moving again. The likely one-man solution (ie, if the whole thing just gets bumped to Steve or a successor) to a failure of a separately-maintained Lisp engine with no XEmacs backup maintainer is the ImageMagick solution, only more drastic: rm -rf xemacs-22; cvs co -rr21_release xemacs Sure, this is pessimistic. But such disasters happen, and we need to be prepared for the possibility, and to have a plan to avoid it. This is less likely with Scheme; first, the smaller size of Scheme makes it more likely that one hero can control it, and second, we have a volunteer to deal with it, one who is also an implementor of Scheme himself. Hrvoje> There is no way I can compete with Michael. You don't have to. Not even to get me to agree that CL is the way to go. But Michael's expertise _is_ an advantage for Scheme. It would be nice if you could find someone to play the same role for CL. You don't have to, but it would be nice. Footnotes: [1] Bruno did provide a short and incomplete (it ended in an ellipsis) list of tasks for CLisp. For that matter, so has Michael; his proposal is in pretty generic form. [2] One important exception is Reginald's "software engineering tools" argument. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091