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.