[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7088: `copy-tree' of a vector copy sharing structure.with original
From: |
MON KEY |
Subject: |
bug#7088: `copy-tree' of a vector copy sharing structure.with original |
Date: |
Fri, 24 Sep 2010 01:19:13 -0400 |
On Thu, Sep 23, 2010 at 4:41 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 23/09/10 06:28, MON KEY wrote:
>>
>> (let ((orig [[a b] [c d] [e f] [g h]])
>> new-cp)
>> (setq new-cp (copy-tree orig))
>
> Some people would have at least considered a quick C-h f copy-tree
> before filing a bug?
>
> You're missing the VECP arg to emacs lisp copy-tree.
>
(let ((orig '((a . b) [c d] [e f] [g h]))
new-cp)
(setq new-cp (copy-tree orig))
(string-equal (elt (elt (prog1 orig
(aset (elt new-cp 1) 0 "bubba")) 1)
0)
"bubba"))
;=> t
The VECP arg wasn't needed in order to copy the vector only to prevent the copy
from sharing structure... This isn't at all clear in the docs.
(let ((orig [(a . b) [c d] [e f] [g h]])
new-cp)
(setq new-cp (copy-tree orig t))
(string-equal (cdr (elt (prog1 orig
(setf (cdr (elt new-cp 0)) "bubba"))
0))
"bubba"))
;=> nil
> Without that, emacs lisp copy-tree is, much like common lisp copy-tree,
> documented to copy trees of _conses_. Conses do of course look pretty like
> 2 element vectors, but they are a separate datatype in emacs lisp.
>
OK. Thank you for taking the time to clarify this.
I read the doc 3 or 4 times and glanced at the sources and it wasn't
clear what the intent of the VECP (a non-predicate BTW) is intended to
accomplish.
Maybe a copy-vector would be better instead of lumping the datatypes together.
Anyhow, sorry for the noise.
--
/s_P\