bug#7088: `copy-tree' of a vector copy sharing structure.with original

bug#7088: `copy-tree' of a vector copy sharing structure.with original

[MON KEY]

When copy-tree copies vectors the copy shares structure with the original.

This is unlike the behavior of copy-tree on a list of lists:

(let ((orig '((a b) (c d) (e f) (g h)))
      new-cp)
  (setq new-cp (copy-tree orig))
  (equal (elt
          (prog1 orig
            (setf (car new-cp) "bubba")) 0)
         '(a b)))
;=> t

(let ((orig [[a b] [c d] [e f] [g h]])
      new-cp)
  (setq new-cp (copy-tree orig))
  (string-equal (aref (prog1 orig
                        (aset new-cp 0 "bubba"))
                      0)
                "bubba"))
;=> t

Shouldn't idx 0 of the orig tree still be [a b]?

Note This bug _should_ prob. have stayed with Bug7083 but that bug
report was prematurely closed.

--
/s_P\

bug#7083: bug#7088: `copy-tree' of a vector copy sharing structure.with original

[Andreas Schwab]

MON KEY <monkey@sandpframing.com> writes:

> When copy-tree copies vectors the copy shares structure with the original.

Works as documented.  A vector is not a cons cell.

If TREE is a cons cell, this recursively copies both its car and its cdr.
             ^^^^^^^^^

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7088: `copy-tree' of a vector copy sharing structure.with original

[David De La Harpe Golden]

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.

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.

ELISP> (let ((orig [[a b] [c d] [e f] [g h]])
       new-cp)
   (setq new-cp (copy-tree orig t))
   (string-equal (aref (prog1 orig
                         (aset new-cp 0 "bubba"))
                       0)
                 "bubba"))
*** Eval error ***  Wrong type argument: stringp, [a b]

bug#7088: `copy-tree' of a vector copy sharing structure.with original

[MON KEY]

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\