From: MON KEY <monkey@sandpframing.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Juanma Barranquero <lekktu@gmail.com>,
Chong Yidong <cyd@stupidchicken.com>,
Andreas Schwab <schwab@linux-m68k.org>,
6878@debbugs.gnu.org
Subject: bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element
Date: Sat, 21 Aug 2010 13:02:47 -0400 [thread overview]
Message-ID: <AANLkTi=+hOdDNzXWqG=6onz7X4xEtnfMJYwAwJnscmKP@mail.gmail.com> (raw)
In-Reply-To: <jwvtyms4bll.fsf-monnier+emacs@gnu.org>
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\
next prev parent reply other threads:[~2010-08-21 17:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 4:19 bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element MON KEY
2010-08-18 7:36 ` Stefan Monnier
2010-08-19 1:51 ` MON KEY
2010-08-19 8:42 ` Andreas Schwab
2010-08-19 14:13 ` MON KEY
2010-08-19 15:51 ` Stefan Monnier
2010-08-19 17:06 ` MON KEY
2010-08-19 14:47 ` Stefan Monnier
2010-08-19 15:04 ` Andreas Schwab
2010-08-19 16:18 ` Chong Yidong
2010-08-19 17:09 ` MON KEY
2010-08-19 18:40 ` Juanma Barranquero
2010-08-19 23:24 ` Chong Yidong
2010-08-20 2:01 ` MON KEY
2010-08-20 2:23 ` Juanma Barranquero
2010-08-20 18:01 ` MON KEY
2010-08-20 19:49 ` Juanma Barranquero
2010-08-20 23:06 ` MON KEY
2010-08-20 13:02 ` Stefan Monnier
2010-08-20 18:44 ` MON KEY
2010-08-21 12:40 ` Kevin Rodgers
2010-08-21 15:53 ` Andreas Schwab
2010-08-21 17:02 ` MON KEY [this message]
2010-08-18 8:36 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=+hOdDNzXWqG=6onz7X4xEtnfMJYwAwJnscmKP@mail.gmail.com' \
--to=monkey@sandpframing.com \
--cc=6878@debbugs.gnu.org \
--cc=cyd@stupidchicken.com \
--cc=lekktu@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.