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\