[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI 33 vs SLIB
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 <campbell@xxxxxxxxxxxxxxxxxx>
| 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
(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.
(number->string (rotate-bit-field #b0100 3 0 4) 2)
(number->string (rotate-bit-field #b0100 -1 0 4) 2)
(number->string (rotate-bit-field #b110100100010000 -1 5 9) 2)
(number->string (rotate-bit-field #b110100100010000 1 5 9) 2)
| 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)
| > | 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.