Nice work Olin! In fact Gambit-C is already almost 100% compliant with
SRFI 33. Here are my first comments.
> Associative -- n-ary operators, for n >= 0
> bitwise-and i ...
> bitwise-ior i ... Inclusive or
> bitwise-xor i ... Exclusive or
> bitwise-eqv i ... (not (i xor j))
This would be clearer:
bitwise-eqv i ... (lambda args (bitwise-not (apply bitwise-xor args)))
> Non-associative -- exactly two arguments
> bitwise-nand i j (not (and i j))
> bitwise-nor i j (not (ior i j))
> bitwise-andc1 i j (and (not i) j)
> bitwise-andc2 i j (and i (not j))
> bitwise-orc1 i j (ior (not i) j)
> bitwise-orc2 i j (ior i (not j))
I don't understand why bitwise-nand and bitwise-nor are not n-ary.
Also, this would be clearer:
bitwise-nand i ... (lambda args (bitwise-not (apply bitwise-and args)))
etc.
> 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.
> 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.
> insert-bit-field size position new-field i -> exact-integer
How about "replace-bit-field"?
Marc