Re: Is it safe to modify a property list directly with PLIST-PUT?

[pjb@informatimago.com (Pascal J. Bourguignon)]

Teemu Likonen <tlikonen@iki.fi> 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__