n-ary nand & nor; trivial ops; replace-bit-field shivers@xxxxxx 20 Jul 2002 23:19 UTC

```    From: Marc Feeley <xxxxxx@IRO.UMontreal.CA>
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

```