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

*To*: srfi-33@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*Subject*: n-ary nand & nor; trivial ops; replace-bit-field*From*: shivers@xxxxxxxxxxxxx*Date*: Sat, 20 Jul 2002 19:19:57 -0400*Delivered-to*: srfi-33@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*Reply-to*: shivers@xxxxxxxxxxxxx

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. OK, that's a good reason to leave them dyadic instead of variadic. 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, andc2, orc1 and orc2 dyadic. 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 How about "replace-bit-field"? This strikes me as a much better name. I'm going ahead and making the change. Anyone who thinks it's a mistake flame away. Or confirm the decision, if you like it as Marc and I do. -Olin

- Prev by Date:
**bitop APIs in Gambit & Kawa** - Next by Date:
**NAND & NOR now n-ary; Bug in BITWISE-EQV? implementation** - Previous by thread:
**bitop APIs in Gambit & Kawa** - Next by thread:
**NAND & NOR now n-ary; Bug in BITWISE-EQV? implementation** - Index(es):