From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kent M Pitman Newsgroups: gmane.emacs.help Subject: Re: Differences between Elisp and Lisp Date: 29 Apr 2003 09:45:52 -0400 Organization: My ISP can pay me if they want an ad here. Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1051624346 19133 80.91.224.249 (29 Apr 2003 13:52:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2003 13:52:26 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 29 15:52:22 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19AVVA-0004rP-00 for ; Tue, 29 Apr 2003 15:50:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19AVVA-0001hZ-01 for gnu-help-gnu-emacs@m.gmane.org; Tue, 29 Apr 2003 09:50:32 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!petbe.visi.com!uunet!ash.uu.net!sac.uu.net!nntp.TheWorld.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 143 Original-NNTP-Posting-Host: shell01.theworld.com Original-X-Trace: pcls4.std.com 1051623952 27484 199.172.62.241 (29 Apr 2003 13:45:52 GMT) Original-X-Complaints-To: abuse@TheWorld.com Original-NNTP-Posting-Date: Tue, 29 Apr 2003 13:45:52 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-Xref: shelby.stanford.edu gnu.emacs.help:112501 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:8998 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:8998 bojohan+news@dd.chalmers.se (Johan Bockgård) writes: > From gnu.emacs.help, followup-to set to gnu.emacs.help > > "Daniel R. Anderson" writes: > > > On emacswiki.org there is a "wish list". Quite a few people want > > emacs to be based on another version of LISP. Out of curiosity, what > > is it that makes elisp inherently bad, or why would people want it > > to be changed? I hope the following information is taken as constructive. (Why does something in the back of my mind warn me to just decline to respond? Usenet is so unpredictable.) It is impossible to speak on this matter without appearing to invite controversy, but that is not my intent. The question you have asked is clearly a call for opinions and the notes below are just my personal opinion. Others should presumably share their own opinions, and doubtless some will differ from mine, but it would be better if such conflicting opinions were offered in response to your original question than in response to my answer. I don't know that I think that elisp is `inherently bad' so much as `gratuitously different'. That is, a lot of stuff between CL and Lisp are culturally similar, but if you were to read a book on ANSI CL, you would be told to do a lot of stuff that when you try it in elisp doesn't work. A number of Lisp dialects are what they are because they represent a desire to show a new kind of power or a new technique. From where I sit, elisp was not this. It was an attempt to hold onto a vestige of the past, when Common Lisp was emerging and Stallman didn't like it. I urged Stallman at that time to make elisp be compatible with Common Lisp in its core elements so that we could share a user community, but my recollection is that he told me CL had abandoned the dynamic nature (special variables) that were so important to the construction of a scripting language. I would (probably slightly oversimplifying, but for purposes of making a point) characterize elisp as being a dialect that began less "about something" and more "about not-something". For this reason, I think it is linguistically undistinguished. Implementationally, certainly, it has a proud history, but I don't think that history would have gone much differently with a different dialect of Lisp. The key empowerment was the set of emacs-related data structures and the tight integration with emacs. It would be better for Lisp overall if there were fewer dialects [some call them languages], since there would be more cross-play of cultures and there could be more sharing of code, education, etc. (The big question then becomes which dialect to merge with. CL and Scheme present themselves as obvious choices.) I also think, to some degree, that this is an issue of competition among political parties. (My 1995 paper http://www.nhplace.com/kent/PS/Lambda.html is a bit dated in some ways, but addresses the issue of languages as political parties and will clarify (for those who care) what I mean by this, if it's not clear just from context.) That is, Stallman may have wanted to retain a sense of control that perhaps he felt he would lose by going with CL, which at that time was a moving target not controlled by him. ANSI CL is stable for nearly a decade, and being compatible with it no longer means being hostage to a committee, so I don't see that as the political issue it might once have been. And certainly nothing requires one to take all of ANSI CL--one could just subset out the parts that are useful to elisp if there was an issue about not wanting the entire language. Just having the core language align would be very helpful to the Lisp community as a whole. At this point, my understanding is that the Emacs community has come to understand that lexicality is good and that elisp should have gone with it. I know there is some pressure to go with Scheme because it's small and simple, but I think its 'style' is more different than CL's is, and my sense is that changing to Scheme would be a bigger change. That is, I think elisp is more of a Lisp than a Scheme (if you think those two are different, which I do). For example, elisp has multiple namespaces and it would be a point of major incompatibility to move it to a single namespace. Moving to a single namespace [as Scheme does] causes, I claim, the need for a complete overhaul of the macro system. Scheme advocates sometimes assert that their so-called "hygienic macros" are needed by all lisps, and sometimes speak with disdain about Common Lisp for its lack of hygiene, but the truth is that the protective divisions among modules are achieved differently in CL (through package separations and namespace separations), and that allows a consequentially simpler macro system for which I'll here coin the term "aequately hygienic". I also think that in spite of the joy that the Scheme community takes over its 'formal semantics', the fact is that the spec is quite ill-defined on the issue of how to manage unwind-protect exactly because it interacts very badly with call/cc. Because emacs relies heavily on unwind-protect and needs to have deterministic behavior in this area, I really don't recommend getting into the call/cc issue unless you're SURE you have resolved this issue and I really don't see how to resolve the issue without confronting some pretty basic problems in the Scheme design that no one seems to want to admit are even there. See my comp.lang.lisp article http://groups.google.com/groups?selm=sfwn1ic516r.fsf%40world.std.com There is the sometimes issue of tail-call elimination which sometimes separates the CL and Scheme community. CL does not require it, but it does permit it. It would be CL-compliant to make elisp, as either an implementation or subdialect, permit so-called "proper" tail-call elimination (assuming that care was taken not to do this across things that necessarily push stack, like special variable bindings. (I would like to see this part not become a subject of major debate since I think it can be resolved in a way that is favorable to both communities without huge amounts of wasted hot air.) More subjectively, I feel Scheme has an implicit element to it, which is that 'functional programming' is fundamentally empowering. That is, it's not just trying to empower the programmer but also trying to push a particular message about how one ought to feel empowered and, implicitly, how one ought not. Common Lisp is much more agnostic about paradigm, by explicit intent. It tries to offer features that are accomodate those with 'imperative', 'functional', and 'object oriented' styles, leaving it to the programmer to figure out how to structure programs. In my experience, many members of the Scheme community have greeted the variation of options CL provides with disdain because (apparently) it is not about a simple set of common principles. But I, and many CL people, see this simply as an issue of 'tolerance'. The elisp community is very large, and while there will _surely_ be numerous (and probably vocal) Scheme advocates among them, I don't imagine that every one of them wants to be forced into the functional programming mold. Incidentally, I have the same issue with other single paradigm languages--Smalltalk is, like Scheme, a very pretty design but is not how I want to structure _my_ programs, and it doesn't leave room for my way of thinking. One option that would allow both paradigms might be to do like AutoCad did and separate the notion of 'library' and 'datastructures' from the issue of 'language'. In that way, you might be able to design a system where you could elect to program in any of several languages using the same stack, data, error handling as glue between them. In that world, both Scheme and CL (or a CL subset) could survive, as well as perhaps other languages, if someone were interested to provide such. I don't really so much want to keep people from programming in Scheme [if you can address that unwind-protect issue, which I think is a real technical concern] as to assure that people who are used to programming in a certain Lisp style already aren't told they no longer can. If there's a way to frame this as "increasing one's options" instead of "one political party triumphing over another", that would be superior in my view. [Incidentally, thank you for NOT having cross-posted this to multiple communities. I don't think very useful dialog happens that way. I routinely decline to involve myself in cross-posted discussions. http://www.nhplace.com/kent/PFAQ/cross-posting.html ]