> If the trivial ops are provided, it should be noted that they are all
> associative, and hence should all allow extra arguments.  However, for
> only two of them are there good values to use as the result of the
> zero-argument case.

Oops.  Only four are associative.  Appropriate specifications
(ignoring errors) would be:

  (define (bitwise-const0 . args) 0)
  (define (bitwise-const1 . args) -1)
  (define (bitwise-arg1 arg1 . args) arg1)
  (define (bitwise-arg2 arg1 . args)
    (if (null? args) arg1 (apply bitwise-arg2 args)))
  (define (bitwise-not1 x y) (bitwise-not x))
  (define (bitwise-not2 x y) (bitwise-not y))

In light of its associative extension, perhaps bitwise-arg2 is a bad
name, just as bitwise-eqv is a misleading name once you extend it to
more than two arguments.  Maybe bitwise-arg1 and bitwise-arg2 should
be bitwise-first and bitwise-last.

Also, bitwise-not1 and bitwise-not2, although nonassociative, do have
obvious extensions to n-arity (as do nand and nor), if you rename them
to bitwise-not-first and bitwise-not-last.  The same goes for andc1,
andc2, orc1, and orc2.

I think I agree with your initial instinct that all associative
operations should be variadic and all nonassociative ones should not.

I used to consider it a misfeature of r5rs that it lacked /=, but I've
grown to appreciate that this has the advantage of there being no
confusion about whether /= means (lambda args (not (apply = args))) or
the more complicated common lisp meaning: (lambda args (or (null?
args) (and (apply /= (cdr args)) (not (memv (car args) (cdr
args)))))).

-al