[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

*To*: alfresco@xxxxxxxxxxxxx*Subject*: Re: The boolean eqv function & n-ary generalisation of associative ops*From*: Alack Petrofsky <alack@xxxxxxxxxxxxx>*Date*: Sun, 21 Jul 2002 13:31:58 -0700*Cc*: shivers@xxxxxxxxxxxxx, srfi-33@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*Delivered-to*: srfi-33@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*In-reply-to*: <200207211957.MAA28836@xxxxxxxxxxxxxxxxxxxx> (message from Alfresco Petrofsky on Sun, 21 Jul 2002 12:57:51 -0700)*References*: <200207211714.g6LHEDo01095@xxxxxxxxxxxxxxxxxx> <200207211907.g6LJ7Qm01201@xxxxxxxxxxxxxxxxxx> <200207211957.MAA28836@xxxxxxxxxxxxxxxxxxxx>

> 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

**References**:**NAND & NOR now n-ary; Bug in BITWISE-EQV? implementation***From:*shivers

**The boolean eqv function & n-ary generalisation of associative ops***From:*shivers

**Re: The boolean eqv function & n-ary generalisation of associative ops***From:*Alfresco Petrofsky

- Prev by Date:
**Re: The boolean eqv function & n-ary generalisation of associative ops** - Next by Date:
**bitwise-=** - Previous by thread:
**Re: The boolean eqv function & n-ary generalisation of associative ops** - Next by thread:
**Re: The boolean eqv function & n-ary generalisation of associative ops** - Index(es):