From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: gmane.emacs.help Subject: Re: Is it safe to modify a property list directly with PLIST-PUT? Date: Mon, 27 Jul 2009 22:17:33 +0200 Organization: Informatimago Message-ID: <87y6q9g9sy.fsf@galatea.local> References: <87ab2rs8kv.fsf@iki.fi> <87zlargqd3.fsf@galatea.local> <874osy7jk9.fsf@iki.fi> <87k51uh6h0.fsf@galatea.local> <87d47mt3z5.fsf@iki.fi> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248727790 20397 80.91.229.12 (27 Jul 2009 20:49:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 20:49:50 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jul 27 22:49:43 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVX8h-0003Dx-9E for geh-help-gnu-emacs@m.gmane.org; Mon, 27 Jul 2009 22:49:43 +0200 Original-Received: from localhost ([127.0.0.1]:60367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVX8g-0007Lf-Lt for geh-help-gnu-emacs@m.gmane.org; Mon, 27 Jul 2009 16:49:42 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 82 Original-X-Trace: individual.net Xry0M73Vjjmk6rqx486LCAhfwvrTK/sVuuagJKet4oNrJgituu Cancel-Lock: sha1:YmNkODE4NzVmZGY2ZWQ5NmNhZmY4NzJjMDYyNWY5MjI5MDk1OTBiZg== sha1:BSBXj68hbeyMHIbuCwDykBKZaek= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) Original-Xref: news.stanford.edu gnu.emacs.help:171252 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:66437 Archived-At: Teemu Likonen writes: > On 2009-07-27 10:31 (+0200), Pascal J. Bourguignon wrote: > >> No, it wont' always work. The problem occurs when the plist is nil, >> since nil is a constant symbol that is immutable. >> >> (let ((p '())) ; the nil symbol >> (plist-put p :bar 2) >> p) >> --> nil >> >> It seems that in the case of a non-null plist, emacs lisp adds the >> missing key to the tail of the plist (which doesn't incurs any >> additionnal cost, since the plist is already traversed for searching >> the key). It only means that plist-put is a "destructive" function >> when the plist is not null. >> >> >> So if you don't want to store back the result of plist-put, you just >> have to ensure that the plist is not empty. You may initialize them >> with an unused key/value pair. > > Thanks, again. So far I've used Emacs Lisp mostly non-destructively and > functionally. Only recently started to study what's happening on lower > levels. If one seriously needs to assign elements to lists or other > sequences I think SETF is the way. But it's kind of sad that CL > extension is not a first-class citizen in GNU Emacs. > > Have Emacs developers ever considered switching completely to Common > Lisp and implementing the most important Emacs Lisp features on top of > that? AFAIK, Richard Stallman doesn't (or didn't) like Common Lisp. I heard rumors of emacs being rewritten in guile. In any case, you have to realize that most of emacs code is written in emacs lisp, including all the third party tools, and unreleased code. emacs lisp and Common Lisp are sufficiently different that translating all this code would be unpractical or at least quite laborious. On the other hand, there are several emacsen implemented in Common Lisp, such as hemlock (and portable hemlock), climacs. Of course, the main drawback of these emacsen, is that they lack a lot of features of emacs and all the third party emacs tools. But they've got the advantage that programming new features and tools for them is easier, since it's done in Common Lisp instead of emacs lisp. That's why there's LICE, which is a clone of GNU emacs implemented in Common Lisp instead of C. So you can run all the emacs lisp code on LICE. Nothing change much from GNU emacs, but hopefully, you will be able to write emacs stuff in Common Lisp (as if you wrote GNU emacs features in C). The use of emacs-cl is not to be considered with disdain. Indeed, the meta-linguistic properties of lisp, including emacs lisp, allow (theorically) each user to customize emacs using his own favorite programming language. emacs-cl provides a Common Lisp implementation that should allow you to write new emacs tools in Common Lisp. GNU emacs: +------------------------------+ LICE: | +----------+ | +------------------------------+ | | new-mode | | | +------------+ +-----------+ | | +-+----------+-+ | | old-mode | | new-mode | | | +-----------+ | Common Lisp | | +------------+ +---+-------+-| | | old-mode | | (emacs-cl) | | | emacs-lisp | | | | +-+-----------+-+--------------+ | | |<--+ | | | emacs-lisp | |-+------------+-----+ | +------------------------------+ | Common Lisp | | C | +------------------------------+ +------------------------------+ In the case of LICE, you can call from Common Lisp code (such as you new emacs tools), the emacs-lisp functions (they're implemented in Common Lisp in the LICE package), see the little arrow in the diagram. Now, granted, either LiCE and emacs-cl would need more users, and more developers, but they're at least usable, if perfectible. -- __Pascal Bourguignon__