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

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

[Teemu Likonen]

I use a list of property lists to store data. It's like this:

    (setq my-data '((:foo "one" :bar "two")
                    (:foo "three" :bar "four")))

Sometimes I need to modify the data and a command like this seems to
work:

    (plist-put (nth 1 my-data) :bar "New value")

That is, PLIST-PUT modifies the property list and variable MY-DATA
contains now the modified list:

    ((:foo "one" :bar "two")
     (:foo "three" :bar "New value"))

The question: Is this reliable? Is it guaranteed that it will always
modify the list correctly? If not, how would you suggest doing it
instead?

Common Lisp has so nice SETF macro...

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

[Teemu Likonen]

On 2009-07-26 19:38 (+0300), Teemu Likonen wrote:

>     ((:foo "one" :bar "two")
>      (:foo "three" :bar "New value"))

> The question: Is this reliable? Is it guaranteed that it will always
> modify the list correctly? If not, how would you suggest doing it
> instead?

Ah, Emacs Lisp manual effectively says that it's not guaranteed. So,
what would be the best way to modify single values in a list like the
above?


 -- Function: plist-put plist property value
     This stores VALUE as the value of the PROPERTY property in the
     property list PLIST.  It may modify PLIST destructively, or it may
     construct a new list structure without altering the old.  The
     function returns the modified property list, so you can store that
     back in the place where you got PLIST.  For example,

(elisp) Other Plists

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

[Lennart Borgman]

On Sun, Jul 26, 2009 at 6:58 PM, Teemu Likonen<tlikonen@iki.fi> wrote:
> On 2009-07-26 19:38 (+0300), Teemu Likonen wrote:
>
>>     ((:foo "one" :bar "two")
>>      (:foo "three" :bar "New value"))
>
>> The question: Is this reliable? Is it guaranteed that it will always
>> modify the list correctly? If not, how would you suggest doing it
>> instead?
>
> Ah, Emacs Lisp manual effectively says that it's not guaranteed. So,
> what would be the best way to modify single values in a list like the
> above?

setcar (maybe setcdr too).

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

[Pascal J. Bourguignon]

Teemu Likonen <tlikonen@iki.fi> writes:

> I use a list of property lists to store data. It's like this:
>
>     (setq my-data '((:foo "one" :bar "two")
>                     (:foo "three" :bar "four")))

It is never safe to modify literal data!

     (setq my-data (list (list :foo "one" :bar "two")
                         (list :foo "three" :bar "four")))
or:
     (setq my-data (copy-tree '((:foo "one" :bar "two")
                                (:foo "three" :bar "four"))))


> Sometimes I need to modify the data and a command like this seems to
> work:
>
>     (plist-put (nth 1 my-data) :bar "New value")
>
> That is, PLIST-PUT modifies the property list and variable MY-DATA
> contains now the modified list:
>
>     ((:foo "one" :bar "two")
>      (:foo "three" :bar "New value"))
>
> The question: Is this reliable? Is it guaranteed that it will always
> modify the list correctly? If not, how would you suggest doing it
> instead?

It is safe, as long as the property list is not literal data (that
must be considered immutable).

Notice also that like delete, plist-put returns the result, it cannot
always modify the property list in place.  So you have to restore the
result:

   (setf (nth 1 my-data) (plist-put (nth 1 my-data) :bar "New value"))


> Common Lisp has so nice SETF macro...

Of course, emacs has it too:

   (require 'cl) ; put that in your ~/.emacs


-- 
__Pascal Bourguignon__

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

[Teemu Likonen]

On 2009-07-26 22:07 (+0200), Pascal J. Bourguignon wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>>     (setq my-data '((:foo "one" :bar "two")
>>                     (:foo "three" :bar "four")))
>
> It is never safe to modify literal data!

Oh yes, that was a stupid example. MY-DATA is not really created that
way. We can assume this:

>      (setq my-data (list (list :foo "one" :bar "two")
>                          (list :foo "three" :bar "four")))

> Notice also that like delete, plist-put returns the result, it cannot
> always modify the property list in place.  So you have to restore the
> result:
>
>    (setf (nth 1 my-data) (plist-put (nth 1 my-data) :bar "New value"))

Thanks. Now, let's go one step further while still assuming that we are
not using Emacs CL extension (perhaps just for my education). Is this
reliable:

    (let ((item (nth 1 my-data)))
      (setq item (plist-put item :bar "New value")))

At least it seems to be working: the change appears in MY-DATA too:

    ((:foo "one" :bar "two")
     (:foo "three" :bar "New value"))

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

[Pascal J. Bourguignon]

Teemu Likonen <tlikonen@iki.fi> writes:

> On 2009-07-26 22:07 (+0200), Pascal J. Bourguignon wrote:
>
>> Teemu Likonen <tlikonen@iki.fi> writes:
>>>     (setq my-data '((:foo "one" :bar "two")
>>>                     (:foo "three" :bar "four")))
>>
>> It is never safe to modify literal data!
>
> Oh yes, that was a stupid example. MY-DATA is not really created that
> way. We can assume this:
>
>>      (setq my-data (list (list :foo "one" :bar "two")
>>                          (list :foo "three" :bar "four")))
>
>> Notice also that like delete, plist-put returns the result, it cannot
>> always modify the property list in place.  So you have to restore the
>> result:
>>
>>    (setf (nth 1 my-data) (plist-put (nth 1 my-data) :bar "New value"))
>
> Thanks. Now, let's go one step further while still assuming that we are
> not using Emacs CL extension (perhaps just for my education). Is this
> reliable:
>
>     (let ((item (nth 1 my-data)))
>       (setq item (plist-put item :bar "New value")))
>
> At least it seems to be working: the change appears in MY-DATA too:
>
>     ((:foo "one" :bar "two")
>      (:foo "three" :bar "New value"))

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.

-- 
__Pascal Bourguignon__

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

[Teemu Likonen]

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?

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

[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__