And this is a bit more debatable.

In the srfi text, vector->bitvector and reverse-vector->bitvector only takes one argument, bvec.   In the reference implementation, they can take optional start and end arguments.

The reference implementation seems to make more sense, but the srfi is already finalized.



On Tue, Sep 1, 2020 at 2:14 PM Shiro Kawai <xxxxxx@gmail.com> wrote:
One more.

- (make-bitvector-accumulator bit-or-eof) should be (make-bitvector-accumulator).
bit-or-eof is passed to the generated accumulator, not to make-bitvector-accumulator itself.  (Reference implementation does so.)
The description could be "Returns a SRFI-158 accumulator that collects all the bits passed until end-of-file
object.   When an end-of-file object is passed, ..."


On Tue, Sep 1, 2020 at 1:56 PM Shiro Kawai <xxxxxx@gmail.com> wrote:
1. A couple of minor things that can be corrected without notes, I think.

- A line break is missing before (bitvector->vector/int ...) entry
- Signature of (vector->bitvector bvec) should be (vector->bitvector vec)

2. A bit more correction as errata.

- At the beginning, srfi states "It is an error unless all bitvector arguments passed to procedures that accept more than one are of the same length."  However, this restriction doesn't make sense for bitvector-prefix? and bitvector-suffix? (if two bvecs have to be the same length, it is effectively the same as bitvector=?).   Also, it makes sense that bitvector-prefix-length / bitvector-suffix-length accept different length bitvectors.
I think it is an overlook and can be fixed as an errata.  Suggestion: Add "unless otherwise noted" in the specification section, and note the exception in those procedures.

- bitvector-field-rotate says "... by count bits towards high-order", but high-order isn't defined.  The reference implementation rotates left for positive count, which is also consistent with bitvector-logical-shift, so it is clearer to use the same term, e.g.  "toward lower indices when count >= 0 or toward upper indices when count < 0".