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