RE: scheme - my opinion

A lot of this argument depends on how the relationship between XEmacs and emacs lisp is viewed. I haven't spent a lot of time looking at XEmacs code, but when I looked at GNU Emacs code, I always got the impression that lisp was the implementation language and C was a portable "assembly language". It looked to me as if XEmacs had more low level C stuff, but an attempt was made to do a bit of object based programming in order to expose it to the lisp level. Now if emacs lisp is seen as an extension language, then it doesn't much matter what the new extension language is. But if the language is actually going to be the implementation language and the boundary between the lower level and the lisp level will be blurry, then I will argue for common lisp every time for the same reasons that I stated before. I will now attempt to make feints in the direction of answering some of Stephen's questions. 1. The standard better _not_ talk about text objects. This is a general purpose programming language. What one would like is a rich enough substrate, which is standard, upon which to build the abstractions that XEmacs needs. To me this means structures, objects generic functions.( To me it also means a MOP but I wont get into that) 2. I think that call/cc would be impossible to do in common lisp. I think that tail recursion could be done in common lisp. I think that CLOS and the condition system could be done in scheme but close attention would have to be paid to tiny clos to make it efficient and make conditions objects. You also need to have structures participate in the type system. There are no standard structure types in scheme, and everyone who has them has a different syntax. This is mostly because small/elegant and practical are mutually exclusive. :-) Same with object systems. Note that people always seem to make this "small is beautiful" argument for scheme. When you implement something like XEmacs, there will have to be a rich library of functions and macros available for people to implement the XEmacs functionality. Its also going to have to be as well documented as stuff is now. It seems to me to be contrary to scheme to have,for example, doc strings in functions like they are in emacs lisp and common lisp, and it seems a bit weird to implement them if you really want scheme. Sorry, that just popped in my head. On with the answers. 3. Contrary to what Michael says, I think that it will be less emulation going on from emacs lisp to common lisp than from emacs lisp to scheme. We can always ask Kent Pitman what he thinks. :-) Naively, one could imagine havine an emacs-lisp-user package like the standard defined common-lisp-user package except that in this package, all variables are special and the let acts something like fluid-let which is defined in some schemes. In addition to an emacs-lisp mode, you could also have an emacs-common-lisp mode. Both modes are package aware and when you send regions or definitions to XEmacs, the code gets evaluated in the correct semantic environment. 4. I would say that semantically, the way most people use emacs lisp would change less going from emacs lisp to common lisp than to scheme. Michael brings up the let issue, I bring up documentation strings which are part of defun I like the documentation being in the function, part of the doc string. Javadoc annoys the heck out of me and that's probably what you will have to do using scheme unless you propose to change define to be non standard or to create a defun macro. If you create a defun macro, why use scheme? Anyway, people who get their kicks dusting off obscure corners of languages might complain but I would bet that if we made the *scratch* buffer be an inferior emacs-lisp mode and have the .emacs eval in the emacs-lisp-user environment, most people probably wont notice. God! That's naive! :-) While I think that call/cc is way cool, I have to say that I believe that less than 1% of the people who hack serious lisp will notice its presence. Quite a lot more will notice your object system. It would be way cool to be able to point them to point the serious users to Sonya Keene's book which provides better documentation on OO programming in CLOS than I ever could and Paul Grahms' books. I would think that this kind of documentation would make it easier for both the serious user and the end user. On the scheme side, even after reading all of the wonderful scheme books out there, of which I own several, you still don't know squat about using the more powerful features in scheme48, drscheme, or Rscheme. That's not a good thing. 5. I know that both clisp and scheme48 have foreign function APIs that should be up to the task. Like I said before it would be a bad thing for a general purpose programming language to define things like editing buffers or multilingual text processing, frames or extents. They are sure to get them wrong. :-) We want the proper abstraction power tools to allow us to define what needs to be written at a lower level, what needs to be at a higher level and how to make the boundary nice and neat. In scheme I think that you would have to define your char types to be unicode by default. I am probably wrong. Having a standard just reduces the number of non-standard fundamental language extensions you need like a low level macro system, records/structures, objects, and conditions. You would like the semantics of these things to have been worked out through blood, sweat, and usage and not have to worry about having to change the semantics because now they are not powerful enough. Since we are the system implementors, the boundary between the language and the system (whatever that means in this context) will be fuzzy anyway. My whole take on the this was that since this is a big project and lots of people all over the planet have fun filling the kitchen sink, that it would be nice to have a language that would give you better engineering control over the system. From an end users perspective, the language is just an extension language. I could use scheme just as well. I would NOT use perl. :-) I probably didn't answer everything, but since its 1:30am, you can point out what I missed and I can answer it another time. -Reggie -----Original Message----- From: owner-xemacs-beta(a)xemacs.org [mailto:owner-xemacs-beta＠xemacs.org]On Behalf Of Stephen J. Turnbull Sent: Sunday, July 12, 1998 9:24 PM To: XEmacs Beta Test Subject: Re: scheme - my opinion 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