> Forgive the pedantry.

I appreciate it :) I have adopted basically all suggestions.

 > * I hate to raise this issue again, but are you committed to using “it
   is an error” in this SRFI?  I understand that it modifies things from
   R7RS-small, where “it is an error” has currency.

I don't see an issue with it. This SRFI defines procedures that are
supersets of the behavior of the R7RS procedures. There are still some
situations where “it is an error,” such as calling them with a
non-integer as *start* or *end*. “Undefined behavior” as a term is less
used and runs into some, well, undefined nuanaces. Here is a quote from
Procedural (which was copied from Macrological), emphasis added:

 > Undefined behaviour (and similar phrases such as the behaviour is
undefined… is the direct equivalent of “it is an error” in the
R7RS-Small and the R6RS. An implementation is allowed to behave in any
way at all if instructed to evaluate code with undefined behaviour;
*however, implementers should be aware of the R6RS's guarantee of
safety, a version of which is expected to be applied to the libraries
defined by the R7RS-Large, including to situations which involve
undefined behaviour.*

I don't understand the R6RS safety guarantee (it is either a truism, or
is too poorly defined to be useful as a standard). Plus it seems that
“it is an error” is a little less scary than the term “undefined behavior.”

-- Peter McGoron