The SRFI-33 integer bitwise-operation library -*- outline -*- Olin Shivers First draft: 1996/6/3 Last update: 2002/7/21 Emacs should display this document in outline mode. Say c-h m for instructions on how to move through it by sections (e.g., c-c c-n, c-c c-p). * Table of contents ------------------- Abstract Function index Function Specification Rationale & general discussion Summaries of related designs Reference implementation Topics to be resolved during discussion phase SIZE/POSITION vs. FROM/TO field specs Order of arguments for non-bitstring parameters The name "bit-set?" References & Links Copyright ------------------------------------------------------------------------------- * Abstract ---------- R5RS Scheme has no utilities for performing bitwise logical operations on integers or bitstrings, which is a problem for authors of portable code. This SRFI proposes a coherent and comprehensive set of these functions; it is accompanied by a reference implementation of the spec in terms of a set of seven core operators. The reference implementation is - portable - efficient - completely open, public-domain source The precise semantics of these operators is almost never an issue. A consistent, portable set of *names* and *parameter conventions*, however, is. Hence this SRFI. ------------------------------------------------------------------------------- * Function index ---------------- bitwise-not bitwise-and bitwise-ior bitwise-xor bitwise-eqv bitwise-nand bitwise-nor bitwise-andc1 bitwise-andc2 bitwise-orc1 bitwise-orc2 arithmetic-shift bit-count integer-length bitwise-merge bit-set? any-bits-set? all-bits-set? first-set-bit extract-bit-field test-bit-field? clear-bit-field replace-bit-field copy-bit-field ------------------------------------------------------------------------------- * Function specifications ------------------------- In a Scheme system that has a module or package system, these functions should be contained in a module named "bitwise-lib". They may additionally be provided as part of the general suite of numerical operations. In the following function specifications all parameters are exact integers; unless otherwise indicated, all return values are exact integers. It is an error to pass values of other types as arguments to these functions. Bitstrings are represented by integers, using a two's-complement encoding of the bitstring. Thus every integer represents a semi-infinite bitstring, having either a finite number of zeroes (negative integers) or a finite number of ones (non-negative integers). The bits of a bitstring are numbered from the rightmost/least-significant bit: bit #0 is the rightmost or 2^0 bit, bit #1 is the next or 2^1 bit, and so forth. bitwise-not i -> exact-integer Bitwise logical negation, i.e., -(i+1). (bitwise-not 10) => -11 (bitwise-not -37) => 36 N-ary operators, for n >= 0 Procedure Bit function ------------------ --------------------------------- bitwise-and i ... And bitwise-ior i ... Inclusive or bitwise-xor i ... Exclusive or bitwise-eqv i ... (eqv b1 b2) = (not (xor b1 b2)) bitwise-nand i ... (not (and b ...)) bitwise-nor i ... (not (or b ...)) Note that the and, ior, xor and eqv operations are associative. Exactly two arguments Procedure Bit function ----------------- ----------------- bitwise-andc1 i j (and (not bi) bj) bitwise-andc2 i j (and bi (not bj)) bitwise-orc1 i j (ior (not bi) bj) bitwise-orc2 i j (ior bi (not bj)) Trivial, hence not provided Procedure Definition ----------------- ------------------------------ bitwise-const0 i j (lambda (i j) 0) bitwise-const1 i j (lambda (i j) -1) bitwise-arg1 i j (lambda (i j) i) bitwise-arg2 i j (lambda (i j) j) bitwise-not1 i j (lambda (i j) (bitwise-not i)) bitwise-not2 i j (lambda (i j) (bitwise-not j)) - These 16 procedures correspond to the complete set of two-argument boolean functions, that is, the complete set of bit x bit -> bit functions. For each such function, the corresponding bitwise operator maps that function across a pair of bitstrings in a bit-wise fashion. I have chosen to provide the full set, barring the last, trivial group of six. The core idea of this group of functions is this bitwise "lifting" of the set of dyadic boolean functions to bitstring parameters; the variadic generalisations are made where sensible. - The n-ary functions have these base, nullary cases: (bitwise-and) => -1 (bitwise-ior) => 0 (bitwise-nand) => 0 (bitwise-nor) => -1 (bitwise-xor) => 0 (bitwise-eqv) => -1 - Note that (bitwise-eqv a b c) does *not* produce a 1 bit everywhere a, b & c all agree. That is, it does *not* produce (bitwise-ior (bitwise-and a b c) (bitwise-and (bitwise-not a) (bitwise-not b) (bitwise-not c))) Rather, it produces (bitwise-eqv a (bitwise-eqv b c)) or the equivalent (bitwise-eqv (bitwise-eqv a b) c) - Examples (bitwise-ior 3 10) => 11 (bitwise-and 11 26) => 10 (bitwise-xor 3 10) => 9 (bitwise-eqv 37 12) => -42 (bitwise-and 37 12) => 4 (bitwise-nand 11 26 12) => -9 (bitwise-nor 11 26 12) => -32 arithmetic-shift i count -> exact-integer Arithmetic left shift when COUNT>0; right shift when COUNT<0. (arithmetic-shift 8 2) => 32 (arithmetic-shift 4 0) => 4 (arithmetic-shift 8 -1) => 4 (arithmetic-shift -100000000000000000000000000000000 -100) => -79 bit-count i -> nonnegative-exact-integer Population count of 1's (i >= 0) or 0's (i < 0). (bit-count 0) => 0 (bit-count -1) => 0 (bit-count 7) => 3 (bit-count 13) => 3 ;Two's-complement binary: ...0001101 (bit-count -13) => 2 ;Two's-complement binary: ...1110011 (bit-count 30) => 4 ;Two's-complement binary: ...0011110 (bit-count -30) => 4 ;Two's-complement binary: ...1100010 (bit-count (expt 2 100)) => 1 (bit-count (- (expt 2 100))) => 100 (bit-count (- (1+ (expt 2 100)))) => 1 integer-length i -> nonnegative-exact-integer The number of bits needed to represent I, i.e. (ceiling (/ (log (if (negative? integer) (- integer) (+ 1 integer))) (log 2))) For i >= 0, this is the number of bits needed to represent I in an unsigned binary representation. For all i, (+ 1 (integer-length i)) is the number of bits needed to represent i in a signed, twos-complement representation. (integer-length 0) => 0 (integer-length 1) => 1 (integer-length -1) => 0 (integer-length 7) => 3 (integer-length -7) => 3 (integer-length 8) => 4 (integer-length -8) => 3 bitwise-merge mask i0 i1 -> exact-integer Merge the bitstrings I0 and I1, with bitstring MASK determining from which string to take each bit. That is, RESULT[k] := if MASK[k] = 0 then I0[k] else I1[k]. or (bitwise-ior (bitwise-and (bitwise-not mask) i0) (bitwise-and mask i1)) bit-set? index i -> boolean Is bit INDEX set in bitstring I? INDEX is a non-negative exact integer. The rightmost/least-significant bit in the bitstring is bit 0. (bit-set? 1 1) => false (bit-set? 0 1) => true (bit-set? 3 10) => true (bit-set? 1000000 -1) => true (bit-set? 2 6) => true (bit-set? 0 6) => false any-bits-set? test-bits i -> boolean all-bits-set? test-bits i -> boolean Determines if any / all of the bits set in bitstring TEST-BITS are set in bitstring I. I.e., return (not (zero? (bitwise-and TEST-BITS I))) or (= TEST-BITS (bitwise-and TEST-BITS I))) respectively. first-set-bit i -> exact-integer Return the index of the first (smallest index) 1 bit in bitstring I. Return -1 if I contains no 1 bits (i.e., if I is zero). (first-set-bit 1) => 0 (first-set-bit 2) => 1 (first-set-bit 0) => -1 (first-set-bit 40) => 3 (first-set-bit -28) => 2 (first-set-bit (expt 2 99)) => 99 (first-set-bit (expt -2 99)) => 99 extract-bit-field size position i -> exact-integer test-bit-field? size position i -> boolean clear-bit-field size position i -> exact-integer replace-bit-field size position new-field i -> exact-integer copy-bit-field size position from to -> exact-integer These functions operate on a contiguous field of bits (a "byte," in Common-Lisp parlance) in a given bitstring I. SIZE and POSITION are non-negative exact integers specifying the field: it is the SIZE bits running from bit POSITION to bit POSITION+SIZE-1. - EXTRACT-BIT-FIELD returns the designated bit field from I, shifted down to the least-significant position in the result. - TEST-BIT-FIELD? returns true if any of the field's bits are set in bitstring I. - CLEAR-BIT-FIELD returns I with the selected field's bits zeroed out. - REPLACE-BIT-FIELD returns I with the designated bit field replaced by the least-significant SIZE bits in NEW-FIELD. - COPY-BIT-FIELD returns TO with the selected field's bits replaced by the same field's bits in FROM. ------------------------------------------------------------------------------- * Rationale & general discussion -------------------------------- - These operations interpret exact integers using two's-complement representation; integers thus represent semi-infinite bit-strings. They are only defined for exact integer arguments. - It is not optional for the associative bitwise ops to be n-ary instead of merely binary. They are required to be n-ary. Programmers can *reliably* write BITWISE-AND with 3 arguments, for example. - This design mirrors the structure of Common Lisp's pretty closely. Here are some differences: + "load" and "deposit" are the wrong verbs (e.g., Common Lisp's LDB and DPB ops), since these guys have nothing to do with the store. I chose "extract" and "replace." + Common Lisp's byte datatype doesn't seem to buy you anything over just spelling out size & position, or [start,end) values. + I punted BOOLE; it is not one with the Way of Scheme. Boolean functions are directly encoded in Scheme as first-class functions. + My name choices are more in tune with Scheme conventions (hyphenation, using "?" to mark a predicate, etc.). Common Lisp's name choices were more historically motivated, for reasons of backward compatibility with Maclisp and Zetalisp. + I punted the prefix "log" in favor of "bitwise-" (e.g, LOGNOT, BITWISE-NOT) * The integer ops are no more "logical" than the #f/#t ops, so the "log" prefix is misleading. * The integer ops are bitwise in nature; the prefix "bitwise-" more accurately reflects what they do. * There is general agreement among people I've polled that this is the right prefix. + I also punted the 6 trivial binary boolean ops. I kept the six non-trivial but less common ops. - Is the inclusive-or function written "or" or "ior"? This kind of thing trips me up all the time when I use these types of functions. In my design, there's a simple rule: it is *never* simply "or." The "or" always has modifiers -- "xor," "ior," "nor," "orc1," and "orc2." As it turns out, my boolean op names are *exactly* Common Lisp's. Although that was not an important criterion for the design, it's an extra plus. - Why not a minimal set of ops? I included extra and redundant functions such as BIT-COUNT, BITWISE-NOR, and the bit-field ops in my design. Doing so helps readability, writability, and efficiency. + Readability: Settling on a standard choice of names makes it easier to read code that uses these sorts of operations. It also means computations can be clearly expressed using the more powerful ops rather than synthesized with a snarled mess of BITWISE-AND's, -OR's, and -NOT's. Most of these derived ops are simple to implement in under three lines of code. Providing a basic implementation does not put a burden on the implementor. In fact, all but seven of the ops can be defined in 31 lines of code, which I append below. What we gain is having an agreed-upon set of names by which we can refer to these functions. + Writability: The programmer doesn't have to re-implement these functions, and stumble over the boundary cases and error checking. The programmer can express himself using a full palette of building blocks. + Efficiency: Compilers can directly implement these ops for great efficiency gains without requiring any tricky analysis. If you believe in "small is beautiful," then what is your motivation for including anything beyond BITWISE-NAND? - Why no "logical" right or left shift operations? Because they are not well defined on general integers; they are only defined on integers in some finite range. Remember that, in this library, integers are interpreted as *semi-infinite* bit strings that have only a finite number of ones or a finite number of zeroes. "Logical" shifting shifts bit strings of some fixed size. If we shift left, then leftmost bits "fall off" the end (and zeroes shift in on the right). If we shift right, then zeroes shift into the string on the left (and rightmost bits fall off the end). So to define a logical shift operation, *we must specify the size of the window.* Typically this is the width of the underlying machine's register set (e.g., 32 bits). This is blatantly machine-specific & unportable, and clearly not the right thing for Scheme's more machine-independent general integers. For Scheme's integers, arithmetic shift is the right thing. Note that this situation pertains as well in Common Lisp, and Common Lisp does exactly what this SRFI does: arithmetic shift, but no logical shift. If we were to define a "width 32" or "width 64" or "fixnum" integer datatype, then we could meaningfully define logical shift for these values. Alternately, we could define a "general" logical shift operation that took as an extra argument the size of the bitstring. At this point, we are bending over backward to force-fit an operation into Scheme that fundamentally doesn't belong. Arithmetic shift is the right thing for general integers. - In June 1996, this proposal went through a round of discussion on the Net, in particular with Will Clinger and Aubrey Jaffer. This resulted in several updates: - The functions were explicitly required to operate only on exact integers. - ASH was renamed ARITHMETIC-SHIFT. - BIT-COUNT was preferred to POP-COUNT and POPULATION-COUNT. Note that, as Clinger points out, "BIT-" is the proper prefix for this operation. After the discussion converged, the proposal sat on my disk for six years. - This is a purely functional, side-effect-free implementation of bit operations -- all operations produce new, fresh results, rather than modifying old values. This can be implemented very efficiently for small bit vectors -- small enough to be unboxed values. Algorithms that work on larger bit vectors, however (such as data-flow analysis engines), might wish an alternate data-structure and associated set of operations that permits side-effecting or linear-updating operations (or both) on bit vectors. MIT Scheme, for example, provides such a facility. This should be considered for another SRFI. (See the short summary of the MIT Scheme system below.) I suggest that the design of such a system be deferred until SRFIs for strings and vectors have been finalised. Than a bit-vector SRFI could be designed that would preserve common structure with these other SRFIs, as well as the bitwise library in this SRFI. Note also that finite bit vectors have an isomorphism to finite sets. The design of both set-package and bit-vector SRFIs would probably want to keep this in mind -- maintaining parallel functional structure in the design. ------------------------------------------------------------------------------- * Summaries of related designs ------------------------------ Below are summaries of the related libraries currently found in Common Lisp, PLT Scheme, slib, Bigloo, Scheme 48, Kawa, and MIT Scheme. I was unable to find anything for Gambit. ** Common Lisp ============== lognot n Associative: log{ior,xor,and,eqv} Non-associative: log{nand,nor,andc1,andc2,orc1,orc2} (boole op i j) op one of boole-{clr,set,1,2,c1,c2,and,ior,xor,eqv,nand,nor, andc1,andc2,orc1,orc2} (logtest testbits n) ; #t if any of the 1 bits in TESTBITS are set in N. (not (zerop (logand x y))) (logbitp index n) ; #t if bit # INDEX in N is set. (not (zero? (logand n (ash 1 index)))) ash n count logcount n ; pop-count integer-length n A CL byte is a contiguous field of bits in an int. (byte size position) -> byte-specifier (byte-size byte-spec) -> int (byte-position byte-spec) -> int (ldb bytespec n) ; Extracted byte is shifted down to lsb position. (ldb-test bytespec n) #t if any bits in the byte are 1's. (mask-field bytespec n) Zero out all bits not in bytespec. (dpb newbyte bytespec n) ; Replacement bits are low bits of newbyte (deposit-field from bytespec n) ; Replacement bits are (ldb from bytespec) ** PLT Scheme ============= bitwise-ior i1 ... bitwise-and i1 ... bitwise-xor i1 ... bitwise-not i arithmetic-shift i j ** slib ======= Slib has a clone of a chunk of CL's design. It also has (bit-extract n start end) which is like ldb on bits [start,end) of n. ** Bigloo ========= bit-or i1 i2 bit-xor i1 i2 bit-and i1 i2 bit-not i bit-lsh i1 i2 bit-rsh i1 i2 ** Chez ======= General integers: integer-length i ash i count Fixnums: fxlogand i j fxlogor i j fxlogxor i j fxlognot i fxsll i count ("shift left logical") fxsrl i count ("shift right logical") fxsla i count ("shift left arithmetic") fxsra i count ("shift right arithmetic") ** Scheme 48 ============ bitwise-not i bitwise-and i1 ... bitwise-ior i1 ... bitwise-xor i1 ... arithmetic-shift i count ** MIT Scheme ============= Fixnums: fix:not i fix:and i j fix:andc i j fix:or i j fix:xor i j fix:lsh i count MIT Scheme also has a distinct datatype, the "bit vector." A bit vector is *very* different, in that it its elements are mutable -- it is a mutable vector of bits. Constants are written with a sharp-star prefix, e.g. #*11111. (make-bit-string k init) (bit-string-allocate k) (bit-string-copy bs) (bit-string? object) (bit-string-length bs) (bit-string-ref bs k) -> boolean (bit-string-set! bs k) (bit-string-clear! bs k) (bit-substring-find-next-set-bit bs start end) (bit-string-append bs1 bs2) (bit-substring bs start end) (bit-string-zero? bs) (bit-string=? bs1 bs2) (bit-string-not bs) (bit-string-movec! target-bs source-bs) ; Destructive NOT operation (bit-string-and bs1 bs2) (bit-string-and! target-bs1 bs2) (bit-string-andc bs1 bs2) (bit-string-andc! target-bs1 bs2) (bit-string-or bs1 bs2) (bit-string-or! target-bs1 bs2) (bit-string-xor bs1 bs2) (bit-string-xor! target-bs1 bs2) (bit-string-fill! bs init) ; init is a boolean (bit-string-move! target-bs bs) ; Must be of the same length (bit-substring-move-right! source-bs start1 end1 target-bs start2) (unsigned-integer->bit-string length integer) (signed-integer->bit-string length integer) (bit-string->unsigned-integer bit-string) (bit-string->signed-integer bit-string) ** Guile & Kawa =============== logand i1 ... logior i1 ... logxor i1 ... lognot i logtest i j (any-bit-set?) logbit? index i ash i count logcount i integer-length i bit-extract i start end ------------------------------------------------------------------------------- * Reference implementation -------------------------- There are 24 functions in the spec. 15 can be defined in under two lines of code; REPLACE-BIT-FIELD needs three lines; and BITWISE-EQV needs five. This is not an onerous implementation load; I provide the code below. As this is only 31 lines of code, it hardly seems reasonable to bother discussing copyright. To lay the issue to rest, I am the sole author, and I place it in the public domain. That leaves 7 basic functions that must be primitively defined for each implementation: BITWISE-{NOT,AND,IOR,XOR}, ARITHMETIC-SHIFT, BIT-COUNT, and INTEGER-LENGTH. Slib has implementations of even these functions using R4RS arithmetic, so a simple-minded implementation again doesn't need to do much to support them -- however, slib's general implementations are terribly inefficient relative to native support and should *not* be used except in case of dire emergency. (It's quite clever code, nonetheless, to provide the semantics with such little support.) A good implementation might choose to provide direct compiler/interpreter support for these derived functions, or might simply define them to be integrable -- i.e., inline-expanded. The n-ary BITWISE-EQV function should also receive primitive compiler/interpreter support so that the expensive n-ary mechanism is not invoked in the standard cases -- that is, an application of BITWISE-EQV should be rewritten into an equivalent tree applying some two-argument primitive to the arguments, in the same manner that statically-known n-ary applications of associative operations such as + and * are handled efficiently: (bitwise-eqv) => -1 (bitwise-eqv i) => i (bitwise-eqv i j) => (%bitwise-eqv i j) (bitwise-eqv i j k) => (%bitwise-eqv (%bitwise-eqv i j) k) (bitwise-eqv i j k l) => (%bitwise-eqv (%bitwise-eqv (%bitwise-eqv i j) k) l) ;;; The seven non-trivial boolean functions in terms ;;; of not, and, or & xor. (define (bitwise-nand i j) (bitwise-not (bitwise-and i j))) (define (bitwise-nor i j) (bitwise-not (bitwise-ior i j))) (define (bitwise-andc1 i j) (bitwise-and (bitwise-not i) j)) (define (bitwise-andc2 i j) (bitwise-and i (bitwise-not j))) (define (bitwise-orc1 i j) (bitwise-ior (bitwise-not i) j)) (define (bitwise-orc2 i j) (bitwise-ior i (bitwise-not j))) (define (bitwise-eqv . args) (let lp ((args args) (ans -1)) (if (pair? args) (lp (cdr args) (bitwise-not (bitwise-xor ans (car args)))) ans))) ;;; Helper function -- make a mask of SIZE 1-bits, e.g. (%MASK 3) = #b111. ;;; Suppose your Scheme's fixnums are N bits wide (counting the sign bit, ;;; not counting any tag bits). This version, due to Marc Feeley, will ;;; handle SIZE in the range [0,N-1] without overflowing to bignums. ;;; (For SIZE >= N, the correct bignum value is also produced.) (define (%mask size) (bitwise-not (arithmetic-shift -1 size))) ;;; This alternate, mathematically-equivalent expression ;;; (- (arithmetic-shift 1 size) 1) ;;; is not as good -- it only handles SIZE in the range [0,N-2] without ;;; overflowing to bignums. ;;; ;;; Finally, note that even Feeley's expression can't build an N-bit mask ;;; without bignum help. This is fundamental, since the interpretation ;;; of fixed-size fixnum bit patterns as semi-infinite-bit-strings is that ;;; you replicate the high bit out to infinity. So you have to have a ;;; zero "stop bit" appearing after that highest one bit to turn off the ;;; replication of the ones. (define (bit-set? index n) (not (zero? (bitwise-and (arithmetic-shift 1 index) n)))) (define (any-bits-set? test-bits n) (not (zero? (bitwise-and test-bits n)))) (define (all-bits-set? test-bits n) (= test-bits (bitwise-and test-bits n))) (define (bitwise-merge mask n0 n1) (bitwise-ior (bitwise-and mask n1) (bitwise-and (bitwise-not mask) n0))) ;;; Bit-field ops (define (extract-bit-field size position n) (bitwise-and (%mask size) (arithmetic-shift n (- position)))) (define (test-bit-field? size position n) (not (zero? (bitwise-and (arithmetic-shift n (- position)) (%mask size))))) ;; Integrating i-b-f reduces nicely. (define (clear-bit-field size position n) (replace-bit-field size position 0 n)) ;;; Oops -- intermediate ARITHMETIC-SHIFT can fixnum-overflow on fixnum args. ;(define (replace-bit-field size position newfield n) ; (copy-bit-field size position (arithmetic-shift newfield position) n)) ;;; This three-line version won't fixnum-overflow on fixnum args. (define (replace-bit-field size position newfield n) (let ((m (%mask size))) (bitwise-ior (bitwise-and n (bitwise-not (arithmetic-shift m position))) (arithmetic-shift (bitwise-and newfield m) position)))) (define (copy-bit-field size position from to) (bitwise-merge (arithmetic-shift (%mask size) position) to from)) ;; Simple definition ;(define (first-set-bit i) ; (and (not (zero? i)) ; (let lp ((j 0) (i start)) ; (if (bit-set? i 0) j ; (lp (+ j 1) (arithmetic-shift i 1)))))) ;;; Clever definition, assuming you have a fast BIT-COUNT. (define (first-set-bit i) (- (bit-count (bitwise-xor i (- i 1))) 1)) ------------------------------------------------------------------------------- * Topics to be resolved during discussion phase ----------------------------------------------- I particularly solicit comments about the following topics. ** SIZE/POSITION vs. FROM/TO field specs ======================================== Several functions in this library extract-bit-field size position i -> integer test-bit-field? size position i -> boolean clear-bit-field size position i -> integer replace-bit-field size position new-field i -> integer copy-bit-field size position from to -> integer specify a contiguous "field" of bits in a bitstring. There are two conventions we might use to do so: - SIZE/POSITION E.g., "the 8-bit field beginning at bit 3", and - FROM/TO E.g., "the field from bit 3 up to, but not including, bit 11", or, perhaps, "the field from bit 3 up to bit 10, inclusive." FROM/TO specs are conventionally and most usefully "half-open" specs, meaning "all i such that FROM <= i and i < TO" -- the FROM index is included and the TO index is excluded. I have chosen to use SIZE/POSITION instead of FROM/TO for this library. Doing so eliminates any possibility of fencepost errors on the TO endpoint. It is also the convention chosen by Common Lisp. It is not, however, a widely-used convention within Scheme. Most ranges in Scheme are specified with half-open intervals of the [from,to) form (e.g., (substring s from to)). One might argue that SIZE/POSITION is still the right thing for bit fields, as they are, in practice, frequently of fixed size, unlike element ranges in strings or vectors. ** Order of arguments for non-bitstring parameters ================================================== The "bitwise boolean" functions such as BITWISE-AND only take bitstring parameters. But the following 10 functions are different in that they take other *kinds* of parameters (masks, indices, field sizes) that indicate *the exact operation to perform* on the bitstring parameter(s): arithmetic-shift i count -> integer bitwise-merge mask i0 i1 -> integer bit-set? index i -> boolean any-bits-set? test-bits i -> boolean all-bits-set? test-bits i -> boolean extract-bit-field size position i -> integer test-bit-field? size position i -> boolean clear-bit-field size position i -> integer replace-bit-field size position new-field i -> integer copy-bit-field size position from to -> integer Note that in all of these functions, with the sole exception of ARITHMETIC-SHIFT, the bitstring parameter comes last. This is consistent with an "operation currying" convention, wherein the arguments that determine the operation come first, and the actual value upon which we operate comes last. MAP and FOLD, for example, work this way, too. (The "op currying" convention is actually useful in SML; in Scheme, its utility is almost entirely as a mnemonic convention to aid programmers in remembering argument order.) ARITHMETIC-SHIFT is entrenched by long and consistent tradition in the indicated parameter order; it would be a mistake to alter this. Every implementation of Scheme I have checked that offers a bit-shift operation on integers (PLT Scheme, slib, Bigloo, Scheme 48, and MIT Scheme), as well as Common Lisp, uses the "i count" argument order. As an alternative to the "op currying" order, we could use the "data-structure accessor" convention, wherein the data-structure being accessed (the bitstring) comes first, and the "selector" arguments come after. For example, this is the convention used for the functions VECTOR-REF and STRING-REF. One could make the argument that this convention could be reasonably applied to some of these operators, such as BIT-SET? I recommend leaving things as they are, for maximal consistency with a simple rule. This also provides consistency with Common Lisp, whose bitwise functions uniformly use the ops-curry convention (see the "related designs" summary below). ** The name "bit-set?" ====================== BIT-SET? uses the term "bit set," but that sounds like "Is this a set of bits?" as well as the intended "is the bit set?" On the other hand, a set of bits is a not-very-useful notion (there are, after all, only four such sets), so I haven't pre-empted anything we'd ever really want for some other purpose, such as a term like "bit vector" or something... ------------------------------------------------------------------------------- * References & Links -------------------- This document, in HTML: http://srfi.schemers.org/srfi-33/srfi-33.html [This link may not be valid while the SRFI is in draft form.] This document, in simple text format: http://srfi.schemers.org/srfi-33/srfi-33.txt Archive of SRFI-33 discussion-list email: http://srfi.schemers.org/srfi-33/mail-archive/maillist.html SRFI web site: http://srfi.schemers.org/ [CommonLisp] Common Lisp: the Language Guy L. Steele Jr. (editor). Digital Press, Maynard, Mass., second edition 1990. Available at http://www.elwood.com/alu/table/references.htm#cltl2 The Common Lisp "HyperSpec," produced by Kent Pitman, is essentially the ANSI spec for Common Lisp: http://www.xanalys.com/software_tools/reference/HyperSpec/ [R5RS] Revised^5 Report on the Algorithmic Language Scheme, R. Kelsey, W. Clinger, J. Rees (editors). Higher-Order and Symbolic Computation, Vol. 11, No. 1, September, 1998. and ACM SIGPLAN Notices, Vol. 33, No. 9, October, 1998. Available at http://www.schemers.org/Documents/Standards/ ------------------------------------------------------------------------------- * Copyright ----------- This document is copyright (C) Olin Shivers (1998, 1999). All Rights Reserved. However, the program source found in section "Reference Implementation" is by Olin Shivers and explicitly placed in the public domain. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Scheme Request For Implementation process or editors, except as needed for the purpose of developing SRFIs in which case the procedures for copyrights defined in the SRFI process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE AUTHORS AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ------------------------------------------------------------------------------- * Ispell "buffer local" dictionary ---------------------------------- Ispell dumps "buffer local" words here. Please ignore. LocalWords: ops SRFI RS bitstrings ary ior xor eqv nand andc orc const arg CL LocalWords: op neg CL's LDB DPB datatype BOOLE Maclisp Zetalisp LOGNOT Jaffer LocalWords: Clinger lognot boole clr logtest testbits zerop logand logbitp bs LocalWords: logcount int ldb bytespec lsb dpb newbyte slib HTML init ref lib LocalWords: fixnum newfield srfi html txt Rees SIGPLAN movec finalised expt LocalWords: bitstring nullary writability AND's OR's NOT's unboxed PLT LocalWords: SRFIs Bigloo Kawa lsh rsh Chez Fixnums fxlogand fxlogor fxlogxor LocalWords: fxlognot fxsll fxsrl fxsla fxsra logior logxor logbit slib's args LocalWords: inline lp cdr fixnums Feeley bignums bignum Feeley's indices SML LocalWords: accessor pre empted CommonLisp cltl HyperSpec