n-ary nand & nor; trivial ops; replace-bit-field

[shivers@xxxxxxxxxxxxx]

    From: Marc Feeley <feeley@xxxxxxxxxxxxxxxx> 
    Date: Thu, 18 Jul 2002 09:52:40 -0400 

    I don't understand why bitwise-nand and bitwise-nor are not n-ary.

My heuristic is: "associative ops are n-ary." So if you see
    (f x y z)
you don't have to wonder if it is
    (f (f x y) z)
or
    (f x (f y z))
because it's the same. Plus and times fall under this rule, for example. 
However, nand and nor are not associative.

OK, that's a good reason to leave them dyadic instead of variadic.

On the other hand... you are right. There is a *perfectly reasonable*
definition of n-ary nand:
    (nand x1 ... xn) = (not (and x1 ... xn))
and likewise for nor. Hardware guys, for example, have no issue drawing
n-ary nand and nor gates in logic diagrams.

On the other hand, the associative rule makes a nice split between the dyadics
and variadics. If we make nand and nor variadic, we still have to leave andc1,
andc2, orc1 and orc2 dyadic.

I see the advantages of deciding both ways. It won't mess up this library if
we go either way. I think I would resolve this in favor of n-ary nand & nor,
but I would like to hear more opinions before I make a decision.

    >   bitwise-eqv i ...   (not (i xor j))
    This would be clearer:
      bitwise-eqv i ...     (lambda args (bitwise-not (apply bitwise-xor args)))

Too much text goin' on there. I like the short & simple description. (I did
try it both ways when I wrote the original draft.)

    > Trivial, hence not provided
    >   bitwise-const0 i j  (lambda (i j) 0)
    >   bitwise-const1 i j  (lambda (i j) -1)
    >   bitwise-arg1 i j    (lambda (i j) i)
    >   bitwise-arg2 i j    (lambda (i j) j)
    >   bitwise-not1 i j    (lambda (i j) (bitwise-not i))
    >   bitwise-not2 i j    (lambda (i j) (bitwise-not j))

    Given that these are so trivial, I would suggest that they be included
    in the SRFI.

Dude, (lambda (i j) 0) is the clearest way to write that function down
that I know. BITWISE-CONST0 is not an improvement. I know I have a rep for
including the kitchen sink in my libraries, but this is beyond the pale.
The power/weight ratio just doesn't justify adding six more bindings to 
the library.

    > arithmetic-shift i count -> exact-integer
    >     Arithmetic left shift when COUNT>0; right shift when COUNT<0.

    Given that there is no logical shift, wouldn't it be better to call
    this simply "shift" or "integer-shift".  I think the "arithmetic"
    prefix is confusing.

It's the generally accepted term. And logical shift *does* make sense,
if you are willing to fix (or parameterise) a word-size.

    > insert-bit-field  size position new-field i -> exact-integer
    How about "replace-bit-field"?

This strikes me as a much better name. I'm going ahead and making the change.
Anyone who thinks it's a mistake flame away. Or confirm the decision, if you
like it as Marc and I do.
    -Olin