Re: SRFI 33 vs SLIB Aubrey Jaffer 10 Jan 2005 01:31 UTC
I have sent the updated srfi-60, which is quoted below, to the editor. | Date: Fri, 7 Jan 2005 18:45:45 -0800 (PST) | From: Taylor Campbell <xxxxxx@bloodandcoffee.net> | | On Fri, 7 Jan 2005, Aubrey Jaffer wrote: | | > | If it is simply that SLIB was an easier starting point for you, I'd | > | like to suggest a few name changes to bring what names you added | > | closer to SRFI 33's conventions: | > | | > | logical:ones -> bit-mask (%MASK internally in SRFI 33) | > | logical:rotate -> bitwise-rotate | > | > BIT-MASK is a reasonable suggestion. But why BIT-MASK and not | > BITWISE-MASK? | | BIT-MASK returns a mask of N set bits. BITWISE-MASK sounds like it | performs the bitwise 'mask' operation. | (If BIT-MASK sounds like it masks bits, perhaps MAKE-BIT-MASK might be | a good alternative, though that might make it sound like there's a | disjoint bit mask data type, like MIT Scheme's bit strings.) ... logical:ones, which generated an integer with the least significant k bits set. Calls to bit-field could have replaced its uses . But the definition was so short that I just replaced its uses with: (lognot (ash -1 k)) | > ROTATE doesn't work that way. | | I just had another idea for the rotation operation, actually, which | I think may be somewhat better than either BIT-ROTATE or | BITWISE-ROTATE, since the operation is really just to rotate a | field of bits: a procedure whose prototype is (ROTATE-BIT-FIELD | <size> <position> <i> <count>). Not only is this more general -- | it can rotate an arbitrary field of bits, not just the low N ones | for some N, A procedure in slib/logical.scm, logical:rotate, rotated a given number of low-order bits by a given number of bits. This function was quite servicable, but I could not name it adequately. I have replaced it with rotate-bit-field with the addition of a start argument. This new function rotates a given field (from positions start to end) within an integer; leaving the rest unchanged. _Function:_ *rotate-bit-field* /n count start end/ Returns n with the bit-field from start to end cyclically permuted by count bits towards high-order. Example: (number->string (rotate-bit-field #b0100 3 0 4) 2) => "10" (number->string (rotate-bit-field #b0100 -1 0 4) 2) => "10" (number->string (rotate-bit-field #b110100100010000 -1 5 9) 2) => "110100010010000" (number->string (rotate-bit-field #b110100100010000 1 5 9) 2) => "110100000110000" | but the name and parameter ordering are more consistent with SRFI | 33's conventions as well. SRFI-60 range arguments follow the SUBSTRING and array convention of start (inclusive) and end (exclusive) positions as the last arguments to the function. I might choose differently if I were inventing a new language, but Scheme preceedent is there. | > | bit-reverse -> bitwise-reverse | > | > This one jumps bit-lanes. I think bit-reverse is the better | > description. | | Yes, it probably is. However, thinking about it now, perhaps it would | be better yet to offer a REVERSE-BIT-FIELD, like the ROTATE-BIT-FIELD I | suggested above. It would be extended similarly; its prototype would | look like (REVERSE-BIT-FIELD <size> <position> <i>). The bit-reverse procedure was then the only one remaining which took a width argument. So I replaced it with reverse-bit-field. _Function:_ *reverse-bit-field* /n start end/ Returns n with the order of bits start to end reversed. (number->string (reverse-bit-field #xa7 0 8) 16) => "e5" | > | bitwise:laminate -> bitwise-laminate | > | bitwise:delaminate -> bitwise-delaminate | > | > I used bitwise because bits in corresponding lanes are extracted. | > BIT-LAMINATE and BIT-DELAMINATE might be better. | | Er, I don't follow: shouldn't that make BITWISE-... more suitable? On | further consideration, however, I find myself wondering: in what sorts | of applications are these operations, and the Gray codes, useful? They | seem fairly random to me for a general bitwise operations library. All | the other operations, however, are very widely applicable. I could be | wrong, of course, but even a quick grep through a number of your Scheme | packages -- SCM, SLIB, JACAL, FreeSnell, & synch -- reveals only one | use of bit string lamination and Gray codes: in SLIB's phil-spc.scm, | which could just have easily locally defined the operations. I moved the lamination procedures to phil-spc.scm.