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

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

```    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.

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,

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