Jim Rees scripsit:

> As Arthur noticed some of the "/index" cases -- very roughly, most of the
> test cases examples are written with the */index version of the procedure
> in mind, but are shown relative to the non-index version.

Fixed, and the */index versions removed.

> The test case for *vector-append-subvectors* - the "0 2" arguments mean
> only #(a b) is extracted from the first vector, not #(a b c).   So change
> "0 2" to "0 3" or change the expected result to #(a b h i).

Fixed.

> (*vector-binary-search* vec value cmp) ==> not specified what index is
> returned in the cases of ties - are any matching indices acceptable?  The
> least, the greatest?

Specified that any matching indices are acceptable.

> Text for *reverse-list->vector*, "but the resulting LIST contains the
> elements in reverse..." -- should be VECTOR.

Fixed.

> In the spec for *make-vector*, the word "optionally" is misleading.  The
> vector is always filled with FILL, whether the value is supplied by the
> caller or not.

Changed to allow (make-vector 10) to return 10 different values for the
elements, though probably no system takes advantage of this.

> The "fill" functionality in *vector-copy* seems like a bad idea to me.   It
> is conflating a copy operation with an append operation with a filled
> vector.   No other copying procedure in this SRFI includes a fill argument.

Removed, with a note that it is incompatible with SRFI 43.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
A rose by any other name may smell as sweet, but if you called it
an onion you'd get cooks very confused.          --RMS