In the spec for bitwise-fold, I assume "For each bit b of i from bit #0
to bit (integer-length i)" is exclusive of (integer-length i).  Otherwise
the example is wrong.

The example for bitwise-for-each is wrong because that procedure's return
value is unspecified.  I also assume "starting with bit #0 and ending with
bit (integer-length i)" is exclusive of (integer-length i).

Although the draft SRFI says make-bitwise-generator accepts an optional
second argument, it says nothing about the semantics of that argument.
I suspect the optional second argument specifies some number of low-order
bits to ignore.

The prototype for bits->list says it accepts only one argument, but some
of the examples have that procedure accepting a second argument.

According to the draft SRFI, the first argument to bits->list must be
non-negative.  That means test-227 in chibi-test.scm is incorrect.

I saw some previous discussion of how long it took to run chibi-test.scm
with the sample implementation in various systems.  Larceny's implementation
of SRFI 151 is completely independent of the SRFI 151 sample implementation,
which I have not examined.  Excluding compile time and Larceny's start-up
time of about 0.6 seconds for R7RS programs, Larceny's development version
is running the Chibi tests (without test-227) too fast to measure accurately:
roughly 25 to 30 milliseconds.  I therefore suspect much of the time reported
for the various systems was compile/expansion time and startup time, so those
timings are unlikely to provide useful insight into performance of the SRFI
procedures themselves.

Will