[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reviving SRFI-33
| X-Originating-IP: [188.8.131.52]
| Old-Return-Path: <bear@xxxxxxxxx>
| Date: Fri, 19 Dec 2003 11:02:27 -0800 (PST)
| From: bear <bear@xxxxxxxxx>
| Cc: srfi-editors@xxxxxxxxxxxxxxxxx, shivers@xxxxxxxxxxxxx,
| srfi-33@xxxxxxxxxxxxxxxxx, srfi-47@xxxxxxxxxxxxxxxxx
| Resent-From: srfi-47@xxxxxxxxxxxxxxxxx
| X-Mailing-List: <srfi-47@xxxxxxxxxxxxxxxxx> archive/latest/25
| X-Loop: srfi-47@xxxxxxxxxxxxxxxxx
| Resent-Sender: srfi-47-request@xxxxxxxxxxxxxxxxx
| On Fri, 19 Dec 2003, Paulo Jorge de Oliveira Cantante de Matos wrote:
| I think that numbers and strings of bits are sufficiently different
| ideas, and that the differences between them are sufficiently important,
| that I'd support the idea of bitstrings as a separate disjoint type,
| with its own read syntax and everything. So I'd go for something like
| (bitwise-and \1001 \0110) => \1111
| Alternatively, you could regard bitstrings as a kind of vector and
| read/write them using vector syntax. In that case you'd have
| (bitwise-and #(1 0 0 1) #(0 1 1 0) ) => #(1 1 1 1)
| which is how common lisp does it.
Common-Lisp bit vectors read and write as #* followed by 0s and 1s.
(bit-and #*1001 #*0110) => #*0000
| But Common Lisp has typed-vector infrastructure we don't.
SRFI-47 provides typed-arrays, of which typed-vectors are the rank-1
| And suddenly, typed vectors bring us back to the current SRFI-47.
| Should au1 be added to the set of vector types for SRFI-47, with
| bitwise-operations and bitstring<->integer conversions defined on
| bit arrays in a following SRFI?
SRFI-47 already supports bit-vectors with type AT1. There is no
useful distinction between bits as 0 and 1 versus bits as #T and #F
because there is only one 2-element group.