Should copy-tree assume bool vectors are vectors?

Should copy-tree assume bool vectors are vectors?

[Przemysław Kryger]

Hello,

Recently I’ve stumbled on a somewhat surprising behaviour of `copy-tree’
function. Well it was surprising to me at least. The behaviour is that bool
vectors are not copied when VECP argument of `copy-tree’ is non-nil. For
example, my expectation was the following code to not assert:

  (let* ((vec (make-vector 1 nil))
         (bvec (make-bool-vector 1 nil))
         (tree (cons vec bvec))
         (copy (copy-tree tree t)))
    (cl-assert (equal tree copy))
    (aset vec 0 t)
    (aset bvec 0 t)
    (cl-assert (not (equal tree copy)))
    (cl-assert (equal (car tree) vec))
    (cl-assert (not (equal (car copy) vec)))
    (cl-assert (equal (cdr tree) bvec))
    (cl-assert (not (equal (cdr copy) bvec))))

I made that assumption after reading the documentation of `copy-tree’:

> […] With second argument VECP, this copies vectors as well as conses.

and info node of `copy-tree’: 5.4 Building Cons Cells and Lists

> […] However, if VECP is non-‘nil’, it copies vectors too (and operates
  recursively on their elements).

and info node: 6.7 Bool-vectors:

> A bool-vector is much like a vector, except that it stores only the values
  ‘t’ and ‘nil’.

My understanding is that the existing behaviour stems from the fact that
`vectorp’, that `copy-tree’ uses, yields nil for bool vectors. 

I can see at least the following options, but perhaps even better solution can
be found:

1. Do nothing. After all bool vectors are not vectors - `vectorp’ clearly
returns nil, and there is a separate function `bool-vector-p` for the latter.

2. Update documentation to explicitly point out above discrepancy, including
some (all?) aforementioned places and perhaps `vectorp’ and any other relevant
places.

3. Update the code of `copy-tree’ to support copying bool vectors when VECP is
non-nil.

I’m happy to contribute patches, should a need arise to modify anything.
Cheers,
PK