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__