Re: SRFI 33 vs SLIB

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

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
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.