Sudarshan S Chawathe scripsit:

>   * Para just before Procedures section: typo "vlue"

Fixed.

>   * string-cursor-diff: Is there a significance to the use of the
>     phrase "between cursor2 and cursor1" instead of "between cursor1
>     and cursor2"?  Also, is it correct that if the arguments are
>     cursors then the result is always nonnegative but if the arguments
>     are indexes then the result may be negative?  If so, what is the
>     motivation for this difference?

I got the 1 and 2 out of order, so fixed that.  The result is always
positive if the arguments are a valid start/end pair, so I made it say so.

>   * string-every (and string-any): In the last para, the phrase "in
>     the predicate case" seems like a holdover from an earlier version
>     where pred could be a character(-set).  (I realize that is still
>     permitted as an implementation extension, based on the
>     introduction.)

Removed.

>   * string-tabulate: The order of the arguments is reversed from the
>     order used by SRFI-1's list-tabulate.  Is it intentional?  If so,
>     it may be useful to alert the reader to the difference here.

It is intentional and agrees with SRFI 13 and some other SRFIs.  Note added.

>   * (minor) The discussion starting with "Interested functional
>     programmers" could be moved to after the description of
>     string-fold-right in order to avoid a forward reference.

I'm not going to bother with this.

>   * string-unfold-right: I believe "equivalent to string-fold" should
>     read "equivalent to string-unfold".

Already fixed.

>   * string->vector/cursors: Shouldn't the signature "char-list ->
>     string" read "s [start end] -> vector"?  (The latter matches the
>     sample implementation.)  Also, the note about 'substring' seems
>     out of place here.  Does it refer to the difference between
>     substring/cursors and R7RS's substring?

That entry was complete nonsense, a result of a copy and paste that was
incompletely revised.  Fixed.

>   * The sample implementation does not seem to define
>     string-ref/cursor.

It's equated to string-ref just after the definition of string-join.

>   * (minor) substring/cursors: "procedures returns" should read
>     "procedures return" or "procedures each return".  The distinction
>     between substring/cursors and string-copy/cursors may be clearer
>     if there were a reminder here that string-copy/cursors may return
>     a string that shares storage with s.  (It is certainly mentioned
>     earlier, in the Shared storage section, but it is easy to miss,
>     especially if someone is looking up only a few procedures, and
>     also because the two similarly-named procedures in R7RS are
>     synonyms.)

Fixed.

>   * string-take etc.: Is it true that if the result is the entire
>     string s, then an implementation may return either s or a copy of
>     s, but not a copy that shares storage with s (assuming there is
>     such a thing)?  Mostly, I'm trying to understand the significance
>     of distinguishing the case in which the entire string is returned
>     from one that returns a proper substring, which the description
>     mentions separately (here and in a few other places).

The only difference is that any implementation, whether it has
storage-sharing substrings or not, can (but is not required to) share
the whole source string.

>   * (minor) string-index etc.: It may be helpful to include a
>     symmetric comment "If no match is found..." for
>     string-index-right.  I assume the return value will be start in
>     this case.

Done.

>   * (minor) string-contains: Should the example include
>     string-cursor->index to be sure to yield 15 for arbitrary cursor
>     implementations?

That's the implication of "{Cursor 15}".  I have changed the em dash to
two consecutive hyphens (it was changed unintentionally).

>   * (minor) string-concatenate-reverse: missing space after
>     'substring' in example.

It looks all right to me in Chrome and in the source; it may be a layout
problem in your browser.

>   * string-for-each-cursor: The example seems to be missing a
>     string-ref and includes an unused len.  Something like the
>     following could be used:
>
>       (string-for-each-cursor (lambda (i)
>      	                          (write-char (string-ref s i)))
>       										    s)

I'm pretty sure this has been fixed.

>   * string-replicate: Is it an error if from > to?  (This may have
>     been noted somewhere earlier, but I couldn't find it quickly and a
>     reminder here may be good nonetheless.)

It's an error; text added.

>   * (minor) string-split: "Delimiter specifies a string whose
>     characters are to be used as the word separator" could be
>     interpreted to mean that each character in the delimiter string is
>     treated as a separator (as a character-set).  The next sentence
>     does clarify the issue.  However, perhaps replacing "whose
>     characters are" with "that is" would be clearer.

Done.

>   * (minor) string-split: A pointer to SRFI-115's regexp-split (or a
> 	  reminder to use string-split only for simple tasks) may be a good
> 	  addition to the description of string-split.  I found myself
> 	  wondering about why delimiter was limited to a string until I read
> 	  some comments on the mailing list.  (SRFI-13's description of
> 	  string-tokenize provides some text along similar lines, I think.)

Added.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    --Calvin, giving Newton's First Law "in his own words"