[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 33 vs SLIB

This page is part of the web mail archives of SRFI 60 from before July 7th, 2015. The new archives for SRFI 60 contain all messages, not just those from before July 7th, 2015.

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
 | 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)
    => "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.