[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The boolean eqv function & n-ary generalisation of associative ops
> 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