bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

When aref/aset'ing the 0th element of a bool-vectors of length 0 i get
an args-out-of-range error:

(setq tt--bv (make-bool-vector 29 t))
;=> #&29"\377\377\377\x1f"

(vconcat (make-bool-vector 29 t))
; => [t { ... 27 t's ... } t]

(aref tt--bv 0)
;=> t

(aset tt--bv 0 nil)
;=> nil

(setq tt--bv (make-bool-vector 0 t))
;=> #&0""

(vconcat (make-bool-vector 0 t))
;=> []

(aref tt--bv 0)
;=> Debugger entered--Lisp error: (args-out-of-range #&0"" 0)

(aset tt--bv 0 t)
;=> Debugger entered--Lisp error: (args-out-of-range #&0"" 0)

As with the the first bool-vector of length 29 the second bool-vector
of length 0 should also have a value at element 0 that evaluates to
`t'.  (Or, it should according to the manual):

,---- (info "(elisp)Bool-Vector Type")
|
| "A "bool-vector" is a one-dimensional array of elements that must be
| `t' or `nil'."
|
`----

I can't find mention in the docs that the 0th element of a bool-vector
is void for 0 length bool-vectors. Indeed, it isn't at all clear why
it should.

I find this is problematic because there aren't any equivalents to
`car-safe'/`safe-length' for generalized bool-vectors operations.

Obv. taking the 0th index of a vector or char-table also signals an
args-out-of-range error however I belive this for slightly different
reasons.

(setq tt--mv (make-vector 0 t))
;=> []

(vectorp tt--mv)
;=> t

(vectorp tt--bv)
;=> nil

(char-table-p tt--bv)
;=> nil

(vector-or-char-table-p tt--bv)
;=> nil

(arrayp tt--bv)
;=> t

(bool-vector-p tt--bv)
;=> t

(null tt--bv)
;=> nil

(null (append tt--bv))
;=> nil

(null (append tt--bv nil))
;=> t

Maybe something like this is needed:

(defun safe-aref-bool-vector (bool-vector idx)
  (if (and (bool-vector-p bool-vector)
           (not (null (append bool-vector nil))))
      (aref bool-vector idx)
    0))

(defun safe-aset-bool-vector (bool-vector idx)
  (if (and (bool-vector-p bool-vector)
           (not (null (append bool-vector nil))))
      (aset bool-vector idx)
    0))

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Stefan Monnier]

> When aref/aset'ing the 0th element of a bool-vectors of length 0 i get
> an args-out-of-range error:

To have a 0th element, an array needs to be of length >= 1.
So this behavior seems perfectly correct to me.
An array of length N has elements 0..N-1, so an array of length
0 doesn't have any elements at all.  This should be true of strings,
vectors, and bool-vectors.


        Stefan

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Andreas Schwab]

MON KEY <monkey@sandpframing.com> writes:

> As with the the first bool-vector of length 29 the second bool-vector
> of length 0 should also have a value at element 0 that evaluates to
> `t'.  (Or, it should according to the manual):

There is no element 0 in a 0-length bool vector, just like there is no
element 29 in a 29-length bool vector.

> Obv. taking the 0th index of a vector or char-table also signals an
> args-out-of-range error however I belive this for slightly different
> reasons.

In which way are bool vectors different from other vectors?

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#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Wed, Aug 18, 2010 at 3:36 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>> When aref/aset'ing the 0th element of a bool-vectors of length 0 i get
>> an args-out-of-range error:

> To have a 0th element, an array needs to be of length >= 1.

Sure, this is true in the generalized case for an Elisp array.

> An array of length N has elements 0..N-1, so an array of length
> 0 doesn't have any elements at all.

Maybe, but this is not what the manual has to say of the particular type of
array that is a bool-vector, again (note the "must"):

,---- (info "(elisp)Bool-Vector Type")
|
| "A "bool-vector" is a one-dimensional array of elements that must be `t'
| or `nil'."
|
`----

So why would/should Emacs let me create a bool-vectors that I can neither set
nor get without signalling an error?

I can imagine there are situations where making 0 length vanilla vector has
utility because these are "closer" to list representation w/re the _type_ of
contents they can hold and can be reasonable coerced w/ less representational
loss of data but this is not the case w/ bool-vectors because they are _limited_
by the type of data they can represenet. Coercing 0 length bool-vector returns a
bool-vector whereas coercing a like vanilla vector yields a vector e.g.:

(append (make-bool-vector 0 t) '())
;=> #&0""

(append (make-vector 0 1))
;=> []

This presents a presents a problem when one _expects_ a bool-vector to be
treated as a first class array:

(let* ((ab (make-bool-vector 0 t))
       (abeq (cons ab ab)))
  (concat (car abeq) (cdr abeq)))
;=> ""

(let* ((av (make-vector 0 0))
       (aveq (cons av av)))
(concat (car aveq) (cdr aveq)))
;=> ""

Indeed, if we are to believe the above return values the coercion results in two
return values which _are_ `eq':

(let* ((ab (make-bool-vector 0 t))
       (abeq (cons ab ab))
       (av (make-vector 0 0))
       (aveq (cons av av)))
  (eq (concat (car abeq) (cdr abeq))
      (concat (car aveq) (cdr abeq))))
;=> t

However apropos Andreas' question:
> In which way are bool vectors different from other vectors?

Andreas, if your listening this is how:

This works:

(let* ((ab (make-vector 1 116))
       (aseq (cons ab ab)))
(concat (car aseq) (cdr aseq)))
;=> "tt"

This doesn't:

(let* ((ab (make-bool-vector 1 t))
       (abeq (cons ab ab)))
  (concat (car abeq) (cdr abeq)))
;
;=> Debugger entered--Lisp error: (wrong-type-argument integerp t)


Honestly I can't find the utility of 0 length bool-vectors in a lisp system
which doesn't allow tweaking arrays at a lower level than Emacs presently
allows. Maybe bool-vectors were intended (at some point long ago)
to be (or to be eventually) made adjustable :) :

CL-USER> (setq ba (make-array 0 :element-type 'bit :adjustable t))

CL-USER> ba
#*

CL-USER> (adjustable-array-p ba)
T

CL-USER> (array-dimension ba 0)
0

CL-USER> (array-dimensions  ba)
(0)

CL-USER> (adjust-array ba 1)
#*0

CL-USER> ba
#*0

CL-USER> (bit-vector-p ba)
T

CL-USER> (bit ba 0)
0

(setf (bit ba 0) 1)
1

CL-USER> (bit ba 0)
1

CL-USER> ba
#*1

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Andreas Schwab]

MON KEY <monkey@sandpframing.com> writes:

> Maybe, but this is not what the manual has to say of the particular type of
> array that is a bool-vector, again (note the "must"):
>
> ,---- (info "(elisp)Bool-Vector Type")
> |
> | "A "bool-vector" is a one-dimensional array of elements that must be `t'
> | or `nil'."

All elements of (make-bool-vector 0 t) are either t or nil.

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#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Thu, Aug 19, 2010 at 4:42 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> ,---- (info "(elisp)Bool-Vector Type")
>> |
>> | "A "bool-vector" is a one-dimensional array of elements that must be `t'
>> | or `nil'."
>
> All elements of (make-bool-vector 0 t) are either t or nil.
>

Prove it!

Please provide one piece of code that explicitly allows accessing the
`t' at elt 0 and/or distinguishing whether the elt at idx 0 is either
`t' or `nil'.

I can't find a way to do it. Can you?

In the absence of a working example I think you have a bug on your hands.

> Andreas.

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Stefan Monnier]

>> Maybe, but this is not what the manual has to say of the particular type of
>> array that is a bool-vector, again (note the "must"):
>> ,---- (info "(elisp)Bool-Vector Type")
>> | "A "bool-vector" is a one-dimensional array of elements that must be `t'
>> | or `nil'."
> All elements of (make-bool-vector 0 t) are either t or nil.

Indeed, this is trivially (and vacuously) true.  Actually, we can even
say that all elements of a 0-length vector (bool or not) are both nil
and t at the same time.


        Stefan

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Maybe, but this is not what the manual has to say of the particular type of
>>> array that is a bool-vector, again (note the "must"):
>>> ,---- (info "(elisp)Bool-Vector Type")
>>> | "A "bool-vector" is a one-dimensional array of elements that must be `t'
>>> | or `nil'."
>> All elements of (make-bool-vector 0 t) are either t or nil.
>
> Indeed, this is trivially (and vacuously) true.  Actually, we can even
> say that all elements of a 0-length vector (bool or not) are both nil
> and t at the same time.

As long as you don't look at them ;-)

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#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Stefan Monnier]

>>> ,---- (info "(elisp)Bool-Vector Type")
>>> | "A "bool-vector" is a one-dimensional array of elements that must be `t'
>>> | or `nil'."
>> All elements of (make-bool-vector 0 t) are either t or nil.

> Prove it!

Easy! formally, he said:

  ∀ n ≥ 0 ∧ n < 0. (aref (make-bool-vector 0 t) n) ∈ { nil, t }

And since there is no such `n', this is trivially true.
More specifically, "n ≥ 0 ∧ n < 0" is a falsehood, and from false you
can conclude anything you wish.  Among other things you can just
a trivially prove:

  ∀ n ≥ 0 ∧ n < 0. the sky is green


-- Stefan

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Chong Yidong]

MON KEY <monkey@sandpframing.com> writes:

> So why would/should Emacs let me create a bool-vectors that I can
> neither set nor get without signalling an error?

You can vconcat them.

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Thu, Aug 19, 2010 at 11:51 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Prove it!
>
> Easy! formally, he said:
>
>  ∀ n ≥ 0 ∧ n < 0. (aref (make-bool-vector 0 t) n) ∈ { nil, t }
>
> And since there is no such `n', this is trivially true.
> More specifically, "n ≥ 0 ∧ n < 0" is a falsehood, and from false you
> can conclude anything you wish.  Among other things you can just
> a trivially prove:
>
>  ∀ n ≥ 0 ∧ n < 0. the sky is green
>

The problem with the above semantic vodoo is that it doesn't reflect the
contents of the manual either:

,---- (info "(elisp)bool-vectors")
|
| A bool-vector is much like a vector, except that it stores only the
| values `t' and `nil'.  If you try to store any non-`nil' value into an
| element of the bool-vector, the effect is to store `t' there.
|
`----

Informally, your formal proof is valid only so long as we suspend
belief in the manual and the sources which the manual is intended to
inform, specifically the place where it doesn't say that 0 length
bool-vectors don't have a value at index 0. IOW your proofs universal
qualifer relies on an empty domain where the manual would suggest
otherwise.  Since there is no "formal Emacs Lisp specification", and
since we are not discussing the formal realm of denotational semantics
nor first order logic w/ regards to a formal Emacs Lisp specification
your proof is indeed only trivially applicable.

Here is what I think the manual should say:

at info node "Bool-Vector Type"

,----
|
| A "bool-vector" is a special type of one-dimensional array.  An elment
| of a bool-vector which is accesible by its non-zero index must only be
| `t' or `nil'.
|
`----

at info node "Bool-vectors"

,----
|
| A bool-vector is a special type of vector which stores only the values `t'
| and `nil'.  If you try to store any non-`nil' value into an element of the
| bool-vector, the effect is to store `t' there.  As with all arrays,
| bool-vector indices start from 0. Emacs allows creation of a bool-vector of
| length 0 however its length cannot be changed once the bool-vector is created.
| An error is singaled if you try to access the 0 index of a bool-vector of
| length 0.  Bool-vectors are constants when evaluated.
|
`----


--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Thu, Aug 19, 2010 at 12:18 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> MON KEY <monkey@sandpframing.com> writes:
>
>> So why would/should Emacs let me create a bool-vectors that I can
>> neither set nor get without signalling an error?
>
> You can vconcat them.
>

Yep:

(let* ((ab (make-bool-vector 1 t))
      (abeq (cons ab ab)))
 (vconcat (car abeq) (cdr abeq)))

;=>[t t]

But, again, where is the `t' or `nil'?

(let* ((ab (make-bool-vector 0 t))
      (abeq (cons ab ab)))
 (vconcat (car abeq) (cdr abeq)))

;=> []

The manual says a `t' or `nil' "must" be there.

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Juanma Barranquero]

On Thu, Aug 19, 2010 at 19:09, MON KEY <monkey@sandpframing.com> wrote:

> But, again, where is the `t' or `nil'?
>
> (let* ((ab (make-bool-vector 0 t))
>      (abeq (cons ab ab)))
>  (vconcat (car abeq) (cdr abeq)))
>
> ;=> []
>
> The manual says a `t' or `nil' "must" be there.

No, it says that its elements must be either t or nil. And they are,
*all* of them.

    Juanma

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Chong Yidong]

MON KEY <monkey@sandpframing.com> writes:

> The manual says a `t' or `nil' "must" be there.

Admittedly, the wording in the manual makes it possible for a reader to
misinterpret it, if he is determined to do so.  I have changed it to
read

    A @dfn{bool-vector} is a one-dimensional array whose elements must
  be @code{t} or @code{nil}.

which should be less ambiguous.  Thus, I'm closing this bug.

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Thu, Aug 19, 2010 at 7:24 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> MON KEY <monkey@sandpframing.com> writes:
>
>> The manual says a `t' or `nil' "must" be there.
>
> Admittedly, the wording in the manual makes it possible for a reader to
> misinterpret it, if he is determined to do so.  I have changed it to
> read

It isn't the determined reader its the haphazer user...

>
>    A @dfn{bool-vector} is a one-dimensional array whose elements must
>  be @code{t} or @code{nil}.
>
> which should be less ambiguous.  Thus, I'm closing this bug.
>

As you wish. Though, I don't think changing the wording solves the real problem
If there are no good reasons to create a boole-vectro of length 0 why allow it?

FWICG older lisp dialects from which Emacs lisp derives used bit arrays in
special ways e.g. LispM Lisp `bitblt' and `boole' related functions see the Lisp
Machine Manual page 123 (of 484) and page 92 (of 484) of pdf here:
 (URL `http://www.bitsavers.org/pdf/mit/cadr/chinual_3rdEd_Mar81.pdf')

But these systems/dialects allowed array indirction and size extension.

Emacs lisp doesn't and I can think of no good reasons to create 0
length bool-vectors.

Can any one else?

If there are no good reasons to create a boole-vector of length 0 and nothing
good to do with them even when you can do it why allow it to occur in
the first place?

This said, its doubtfull the feature would be missed either way.
Though apparently frobbing the lsb has interesting steganographic utility...

rgrep'ing "make-boole-vector" in lisp/
finds only two active uses of `make-bool-vector' appearing in /lisp:

emacs-lisp/sregex.el's `sregex--char-aux'

play/mpuz.el
`mpuz-found-digits'
`make-bool-vector'

Its use was deprecated in the following places:

lisp/ChangeLog.10
2001-10-21  Miles Bader  <miles@gnu.org>

* wid-edit.el (checkbox): Swap bg/fg colors in image, and invert
  image bits to compensate.  Use `make-string' instead of
  `make-bool-vector' (XBM apparently wants byte-aligned rows).
revno: 40075

:from
!   :off-glyph (create-image (make-bool-vector 49 1)
:to
!   :off-glyph (create-image (make-string 7 0)


lisp/ChangeLog.9
2000-08-09  Stefan Monnier  <monnier@cs.yale.edu>
* emacs-lisp/regexp-opt.el (make-bool-vector): Remove.
revno: 32042

:from
!   (let* ((charwidth 256)				; Yeah, right.
! 	 (charmap (make-bool-vector charwidth nil))
:to
!   (let* ((charmap (make-char-table 'case-table))

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Juanma Barranquero]

On Fri, Aug 20, 2010 at 04:01, MON KEY <monkey@sandpframing.com> wrote:

> Emacs lisp doesn't and I can think of no good reasons to create 0
> length bool-vectors.
>
> Can any one else?

Of course. Eliminating special cases, for example.

(defun split-vec (v p)
  (list (substring v 0 p)
        (substring v p (length v))))

and you can do

  (apply 'vconcat (split-vec V N))

for N in -length(V)..length(V) and get back V

    Juanma

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Stefan Monnier]

> As you wish. Though, I don't think changing the wording solves the
> real problem If there are no good reasons to create a boole-vectro of
> length 0 why allow it?

That's the wrong question. The question is: why not allow them?

> Emacs lisp doesn't and I can think of no good reasons to create 0
> length bool-vectors.
> Can any one else?

The same reasons to create zero-length strings.


        Stefan

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Thu, Aug 19, 2010 at 10:23 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Aug 20, 2010 at 04:01, MON KEY <monkey@sandpframing.com> wrote:
>
>> Emacs lisp doesn't and I can think of no good reasons to create 0
>> length bool-vectors.
>>
>> Can any one else?
>
> Of course. Eliminating special cases, for example.
>

Thank you for taking the time to provide this example.  If you look
back you may notice I've already acknowledged that there is indeed
utility in 0 length vectors, e.g.:

,----
| I can imagine there are situations where making 0 length vanilla
| vector has utility because these are "closer" to list representation
| w/re the _type_ of contents they can hold and can be reasonable
| coerced w/ less representational loss of data but this is not the
| case w/ bool-vectors because they are _limited_ by the type of data
| they can represenet.
`----

And, I gave an example of the pathology:

,----
| (let* ((ab (make-bool-vector 1 t))
|       (abeq (cons ab ab)))
|  (concat (car abeq) (cdr abeq)))
| ;
| ;=> Debugger entered--Lisp error: (wrong-type-argument integerp t)
`----


> (defun split-vec (v p)
>  (list (substring v 0 p)
>        (substring v p (length v))))
>

Where is the boole-vector ???

(substring (make-bool-vector 18 t) 0)
;=> Debugger entered--Lisp error: (wrong-type-argument arrayp #&18"\377\377\x03")

My question was _specifcally_ w/re to bool-vectors
one _can not_ take the substring of a bool-vector.

> and you can do
>
>  (apply 'vconcat (split-vec V N))
>
> for N in -length(V)..length(V) and get back V

FWIW, your friendly (mis)interpreation of the issue helps bolster my
position...  Which is (in part) that it isn't at all obvious that a
bool-vector is not _really_ a vector and behaves differently in most
respects from other the vector-likes.

Your example works for neither 0 length bool-vectors:

(apply 'vconcat (split-vec (make-bool-vector 0 t) 9))
;=> Debugger entered--Lisp error: (wrong-type-argument arrayp #&0"")

Nor the less pathological variety:

(apply 'vconcat (split-vec (make-bool-vector 18 t) 9))
;=> Debugger entered--Lisp error: (wrong-type-argument arrayp #&18"\377\377\x03")

>
>     Juanma

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Fri, Aug 20, 2010 at 9:02 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> As you wish. Though, I don't think changing the wording solves the
>> real problem If there are no good reasons to create a boole-vectro of
>> length 0 why allow it?
>
> That's the wrong question. The question is: why not allow them?

How about Juanma's example earlier wich is a mis-application of substring on
vectors satisfying the predicate `bool-vector-p' e.g. his:

> (defun split-vec (v p)
>  (list (substring v 0 p)
>        (substring v p (length v))))


>
>> Emacs lisp doesn't and I can think of no good reasons to create 0
>> length bool-vectors.
>> Can any one else?
>
> The same reasons to create zero-length strings.
>

I'm not convinced.
Anyhow, my query included the caveat "good reasons" :)

(substring (make-bool-vector 0 t) 0)

;=> Debugger entered--Lisp error: (wrong-type-argument arrayp #&0"")

And, it doesn't really work for vectors either:

(substring (make-vector 0 1) 0)
;=> []

Likewise, where is the sense in these:

(apply 'string (append (make-bool-vector 0 t) nil))
;=> ""

(concat (make-bool-vector 0 t))
;=> ""

When this:
(concat)
;=> ""

and this:
(apply 'string nil)
;=> ""

would suffice.

Note, I _do_ recognize that there is some utility for things like this w/
_vanilla_ vectors:

(defmacro v->empty (&optional char-val-maybe)
  (let ((vvoid (make-symbol "vvoid")))
    `(let ((,vvoid (if (characterp ,char-val-maybe)
                       1 0)))
       (make-vector ,vvoid ,char-val-maybe))))

(v->empty 'not-a-char)
;=> []
(v->empty 32)
;=> [32]
(v->empty)
;=> []

(mapconcat #'identity
           (mapcar  #'(lambda (ve) (concat (v->empty ve)))
                    '(119 'not-a-char 32 nil 111 'nor-inil
                          32 "nope" 119 'nada 33)) "")

But I can't see how the `make-vector' idiom would translate for
`make-bool-vector'.

>        Stefan
>

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Juanma Barranquero]

On Fri, Aug 20, 2010 at 20:01, MON KEY <monkey@sandpframing.com> wrote:
> My question was _specifcally_ w/re to bool-vectors
> one _can not_ take the substring of a bool-vector.

You're right, I misread.

But that's an argument, if at all, to make bool-vectors act like other
vectors (which is to say, to make array/vector primitives to act on
them like they do other vectors), not to make them more different.

    Juanma

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Fri, Aug 20, 2010 at 3:49 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Aug 20, 2010 at 20:01, MON KEY <monkey@sandpframing.com> wrote:
>> My question was _specifcally_ w/re to bool-vectors
>> one _can not_ take the substring of a bool-vector.
>
> You're right, I misread.
>
NP.
So, safe to assume you haven't come up w/ a good reason to take the
0th elt of a bool-vector?

> But that's an argument, if at all, to make bool-vectors act like other
> vectors (which is to say, to make array/vector primitives to act on
> them like they do other vectors), not to make them more different.
>

No. You are wrong about this.

As they are currently implemented it doesn't make sense to operate
directly on the bool-vector
string content because the "string" is only an abstraction of the
data... There isn't actually a string there to operate upon - it is miasma.

More to the point you can't represent a byte as a string, and w/re bool-vectors
the print representation of the string returned is multibyte but represents a
unibyte char! Figuring out how to reliably DTRT w/re the different ways that
Emacs currently conflates multibyte strings with unibyte strings would only
further complicate the existing kluge that is `make-bool-vector'.

What would be _much_ better would be to change the read/print syntax for
`make-bool-vector' from:

(make-bool-vector 29 t)
;=> #&29"\377\377\377\x1f"

to:
(make-bool-vector 29 t)

;=> #&29[#b11111111 #b11111111 #b11111111 #b00011111]

; e.g. (/ 29 8) => 3
;      (% 29 8) => 5

(make-bool-vector 0 t)
;=> #&0[]

(vconcat [#b11111111 #b11111111 #b11111111 #b00011111])
;=> [255 255 255 31]

(apply 'unibyte-string (append [#b11111111 #b11111111 #b11111111
#b00011111] nil))
;=> "\377\377\377\x1f"

Something like that is quite a bit more readable to my eyes (pun intended).

Though I doubt doing anything like this is very high up on anyones
list given the occurences
of `make-boole-vector' in ./lisp


>     Juanma
>

--
/s_P\

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Kevin Rodgers]

MON KEY wrote:
> On Fri, Aug 20, 2010 at 9:02 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
...
>>> Emacs lisp doesn't and I can think of no good reasons to create 0
>>> length bool-vectors.
>>> Can any one else?
>> The same reasons to create zero-length strings.
>>
> 
> I'm not convinced.

And zero-length lists, etc.

Determined, indeed.

-- 
Kevin Rodgers
Denver, Colorado, USA

bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[Andreas Schwab]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> And zero-length lists, etc.

There can be only one.

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#6878: bool-vectors of length 0 signal error when aref/aset the 0th element

[MON KEY]

On Wed, Aug 18, 2010 at 3:36 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> When aref/aset'ing the 0th element of a bool-vectors of length 0 i get
>> an args-out-of-range error:
>
> To have a 0th element, an array needs to be of length >= 1.
> So this behavior seems perfectly correct to me.
> An array of length N has elements 0..N-1, so an array of length
> 0 doesn't have any elements at all.  This should be true of strings,
> vectors, and bool-vectors.
>

Note, a similar such issue was addressed by David Moon during the ANSI Common
Lisp standardization process.

:SEE ftp://ftp.parc.xerox.com/pub/cl/cleanup/old-mail/bit-array-functions.mail.Z

,----
| Date: Tue, 23 May 89 14:42 EDT
| From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
| Subject: Issue: BIT-ARRAY-FUNCTIONS (version 5)
|
| Proposal (BIT-ARRAY-FUNCTIONS:ADD):
|
| Allow the binary bit-array functions referenced above to accept
| arguments of identical rank but unequal dimensions.  Nonexistent
| elements of bit-array-1 or bit-array-2 are assumed to be zero.  If
| the third argument is T or a bit-array, result elements outside the
| bounds of the array must be zero or an error should be signalled.
| If the third argument is NIL or omitted, each dimension of the
| result array is equal to either the corresponding dimension of
| bit-array-1 or the corresponding dimension of bit-array-2.  The
| larger of the two dimensions is used when necessary to hold all the
| nonzero elements of the result, otherwise either the larger or the
| smaller of the two dimensions is used.
|
`----

What is interestingly relevent to this bug report #6788 w/re
bool-vectsrs was Barry Margolin's initial response to Moon's
proposal above:

Date: Mon, 19 Jun 89 13:31 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)

,----
|
| I'd like to suggest an additional change, which seems to be
| consistent with the attitude about use of bit vectors expressed in
| the proposal.  The BIT and SBIT functions should return 0 if asked
| to access outside the bit array.  This would maintain the tautology
|
| 	(bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))
|
| If slowing down these functions (they'd be the only array accessors
| REQUIRED to check the dimensions) is considered unacceptable, then a
| new accessor should be added.
|
`----

Disregarding the fact that Emacs Lisp does not have anything
equivalent to the Common Lisp bit array functions it remains
noteworthy that a similar issue was considered during the Common Lisp
ratification and that a somewhat similar incontinuity was detected
with one aspect of a proposed solution being Margolin's suggestion that:

 "The BIT and SBIT functions should return 0 if asked to access
  outside the bit array."

Indeed, while I was not aware of Margolin's proposal at the time I
filed the current bug report his solution bears striking resemblance
to the one I provided with my initial bug report, namely:

,----
|
| Maybe something like this is needed:
|
| (defun safe-aref-bool-vector (bool-vector idx)
|  (if (and (bool-vector-p bool-vector)
|           (not (null (append bool-vector nil))))
|      (aref bool-vector idx)
|    0))
|
| (defun safe-aset-bool-vector (bool-vector idx)
|  (if (and (bool-vector-p bool-vector)
|           (not (null (append bool-vector nil))))
|      (aset bool-vector idx)
|    0))
|
`----

>
>        Stefan

--
/s_P\