Pierpaolo Bernardi wrote:

> In the description of textual-length and textual-ref: "... These
> procedures are the generalizations of textual-length and textual-ref
> to accept strings as well as texts."
>
> Should be: "These procedures are the generalizations of text-length
> and text-ref ..."

Thank you.  I have fixed that in my local copy, and it will be
fixed in the next draft.

Sudarshan S Chawathe wrote:

>  * textual-any: I am not sure if the description guarantees that
>    textual-any will stop evaluating pred on its textual argument
>    after the first time pred returns true. It seems intuitive, and
>    seems implicit in the description of the return value, but perhaps
>    could be made explicit.

Now explicit in my local copy and will be explicit in the next draft.

>  * textual-tabulate (and textual-count): I'm guessing the argument
>    order chosen here (different from that of textual-filter) is for
>    SRFI-13 and SRFI-130 compatibility (over SRFI-1 compatibility).  I
>    mention it just in case that is not the intention.

The R*RS authors chose a convention in which procedure arguments come
first.  SRFI 1 violated that convention, but SRFI 13 and SRFI 130 went
back to it (apart from some procedures I'll come back to in a different
message).

>  * (fixed?) The sample implementation exports text-tabulate, not
>    textual-tabulate.  The name text-tabulate seems preferable because
>    the returned value is always a text, not just textual.
>
>  * (fixed?) Should textual-unfold be called text-unfold (and
>    similarly for textual-unfold-right)?  (The sample implementation
>    exports the textual- names.)
>
>  * textual-length and textual-ref: I believe the description should
>    read "... are generalizations of text-length and text-ref...".
>
>  * textual-pad and textual-pad-right: Should "characters of textual"
>    read "characters of textual from start to end" (or similar) given
>    the (optional) start and end arguments?  Perhaps that is implied
>    by some earlier text.  A similar comment applies to
>    textual-trim[-right|-both].

All fixed in my local copy and will be fixed in the next draft.

>  * text<? and friends: Are implementations encouraged to use
>    compatible orderings for texts and strings (given the Note and
>    Rationale paragraphs)?

I've added that encouragement to my local copy.  It will be in the
next draft unless someone objects.

>  * textual-append: Should there be a guarantee of the result not
>    sharing storage with any string arguments (similar to the
>    guarantee for textual-concatenate)?

That's covered by the general guarantee in the first sentence on the
section called "Shared storage", but it would be less confusing to add
that guarantee to the description of textual-append or to delete it
from the description of textual-concatenate.  I think I'll leave it
pretty much as is, but prepend "As with textual-append," to that part
of the description of textual-concatenate.

>  * textual-concatenate-reverse: Regarding the optional final-textual,
>    what is the motivation for including an 'end' argument but not a
>    corresponding 'start' argument?  (I guess this is really a SRFI-13
>    question.)  I suspect I'm unaware of some important idiomatic
>    usage here.

I don't know why SRFI 13 has that optional 'end' argument.  I suspect
SRFI 130 has that optional 'end' argument only because SRFI 13 does.
I know SRFI 135 has that optional 'end' argument only because SRFI 13
and SRFI 130 do.

If anyone actually uses that optional 'end' argument or knows why it's
there, please explain its purpose to us.

Will