[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th e
From: |
MON KEY |
Subject: |
bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element |
Date: |
Fri, 20 Aug 2010 19:06:25 -0400 |
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"
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"
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, (continued)
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Chong Yidong, 2010/08/19
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, MON KEY, 2010/08/19
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Juanma Barranquero, 2010/08/19
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Chong Yidong, 2010/08/19
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, MON KEY, 2010/08/19
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Juanma Barranquero, 2010/08/19
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, MON KEY, 2010/08/20
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Juanma Barranquero, 2010/08/20
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element,
MON KEY <=
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Stefan Monnier, 2010/08/20
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, MON KEY, 2010/08/20
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Kevin Rodgers, 2010/08/21
- bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Andreas Schwab, 2010/08/21
bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, MON KEY, 2010/08/21
bug#6878: bool-vectors of length 0 signal error when aref/aset the 0th element, Andreas Schwab, 2010/08/18