While I agree that intent is not reality, it would probably be best to post this question to comp.lang.lisp. I bet that some people there know first hand exactly how painful it was for them. I am confused about your comment about DEFVAR. Since in elisp all variables are dynamic and get shadowed by let, it is not clear to me how this is different from how common lisp treats special variables. Also I didn't know XEmacs had any read macros at all so I am really confused that they have the #+ and #- read macros. Well I guess that #| could be considered a read macro also, it is in common lisp, but that could be set up as a special case. While I agree with your arguments about scheme48, note that it does not run on Alpha, and seems to be a non-trivial port since there are still some 32 bit assumptions hanging around. Also the module system is a little obscure unless one is comfortable with SML. I was sort of hoping that it would be easy to point to Graham's common lisp book and Keene's CLOS book or Dybvig's scheme book and say that the base language looks just like this. The scheme48 module system complicates that some, but if your plan is to attempt to use scheme48 as the XEmacs engine, I certainly would not complain. Its a great system. I would note though that if you look at extended scheme48, it certainly has a lot of features in it that are in common lisp. The only thing missing is CLOS. This is part of the reason I chose to study the genuine article (common lisp) more. :-) -----Original Message----- From: sperber(a)informatik.uni-tuebingen.de [mailto:sperber＠informatik.uni-tuebingen.de] Sent: Thursday, July 02, 1998 11:59 PM To: xemacs-beta(a)xemacs.org Subject: Re: Where do you want to go tomorrow? Many thanks, Reggie, for your arguments on Common Lisp. I plan to put this in a write-up on the Web page for the near future. Naturally, I appreciate it somewhat less than Hrvoje :-) Reggie> There are several arguments for common lisp. Emacs-lisp is a maclisp Reggie> variant and common lisp is designed with the explicit intent to easily Reggie> migrate maclisp programs to common lisp. Intent is not reality. Reggie> The let argument that people were mentioning earlier does not Reggie> really exist because all globals are treated as special Reggie> variables and will be shadowed by a let just like it happens Reggie> in elisp now. As several people have pointed out, this is precisely *not* like it happens in Elisp now. (Also, DEFVAR's intended semantics are not really "I explicitly want dynamic binding for this variable.") If the Elisp semantics change as Hrvoje suggested, a lot of code will have to change with it. I claim that migration to Common Lisp is roughly as expensive as migration to Scheme. Reggie> Third common lisp has the #+ and #- feature reader Reggie> macros which allow you to take advantage of features that may Reggie> or may not be available in the compiled XEmacs system on a Reggie> particular platform like minimal tagbits or CDE. #+ and #- also have huge downsides, especially in an XEmacs setting, which is why they are hopefully going away in XEmacs RSN. Reggie> None of these things are available in standard scheme, and this to me is Reggie> what separates a language designed for properly engineering a complex Reggie> system like XEmacs has become. The perfect example, to me is scheme48. Reggie> Look at the things that were added to the system to make it usable from Reggie> an engineering standpoint and note that its non-standard Reggie> scheme. Note also that Scheme 48 provides portable implementations of almost all of the additions written in totally standard Scheme. Furthermore, Scheme 48 will bootstrap from just about any implementation of R4RS Scheme. -- Cheers =8-} Chipsy Friede, Vvlkerverstdndigung und |berhaupt blabla