Re: SRFI 33 vs SLIB Taylor Campbell 08 Jan 2005 02:45 UTC
On Fri, 7 Jan 2005, Aubrey Jaffer wrote: > | mention in passing in the current document, the very carefully > | thought-out SRFI 33 for the base of this SRFI. > > Its bizarre that I am first criticized for taking preceedent from > SRFI-4 (in SRFI-47); then for not taking preceedent from a withdrawn > SRFI-33. I'm not sure how you find this bizarre. SRFI 4 was finalized in spite of considerable opposition to its homogeneous vector syntax, and on similar grounds I opposed SRFI 47's array syntax; SRFI 33 was withdrawn due, if I remember correctly, to the fact that Olin Shivers did not have the time to finish it. There wasn't, if I'm not mistaken, any serious opposition to major parts of the SRFI. The matter over which I, as you say, criticize you has nothing whatsoever to do with prior- SRFIness. > | In particular, the naming in SLIB seems to be quite ad-hoc -- no > | consistency with the LOGICAL-, BITWISE:, LOG, &c. prefixes --, and > | the set of general bitwise operations is somewhat different from > | that of SRFI 33: some are missing & some are added. Was it simply > | that starting from SLIB was easier at the time, or is there a more > | complete rationale for the conventions you chose? > > I took functions from Common-Lisp which are useful, keeping their > names. Names for new functions should not be common words which could > suffer collisions. Where the common words are the best description, I > add a prefix of the package name or theme followed by `:'. In > packages where only a couple of names are prefixed, this can look > ad-hoc. Using a colon this way is not done in any RnRS or SRFI that I can think of at the moment. Given that SRFI 33 offers all of the procedures that you named with LOG or LOGICAL:, but with more descriptive, non-package- prefixed names, I don't see why you used the ad-hoc naming you did when there's a good, consistent alternative clearly presented already with detailed rationale. > | 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.) > To me, bitwise means that bits are operated on in their bit-lanes, not > affecting other bit-lanes. That sounds reasonable. > 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, but the name and parameter ordering are more consistent with SRFI 33's conventions as well. > ASH is another problem word, but is prior art from Common-Lisp. SRFI 33 extensively discusses prior art. I believe ARITHMETIC-SHIFT, being both in wide use in many Scheme systems and a longer, much more descriptive name in the Scheme spirit, is a better choice than ASH, along with the great many other naming choices in SRFI 33. > | 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>). > | 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.