William D Clinger scripsit:

> >  * 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.

It would be better from a usability point of view if it were required,
so that you could compare a text to an (often literal) string reliably.
Unfortunately, because R7RS allows implementations to do string comparison
any way they like, an implementation cannot be portable without the
gross inefficiency of converting the text argument to a string and
using string<? and friends.  So the whole thing has to be swallowed up
in implementation-dependent behavior.

> >  * 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.

I understand Olin's somewhat terse explanation to be meant for cases
like this.  If you have a function that wants to return a string whose
length is initially unknown but may be very large, you don't want to
allocate the largest possible string and then cut it back.  The usual
technique is to allocate a reasonable-sized string to start with, and
fill it using mutation and a fill index.  If you overflow it, copy the
string's contents into another string twice as long (up to some large
limit, where you need to start growing only linearly).  If you stay
within the limit, you copy the characters only one extra time.

An alternative approach is to allocate a string of some fixed fairly
small size with make-string, and then use mutation to fill it up,
as above.  When the string is full, it is consed onto a list of
previously created strings.  The procedure then terminates by calling
string-concatenate-reverse on the list of strings, and passing the current
(incomplete) string along with the fill index.  The result is a string
that never grows much beyond the actually needed size and is copied
only once.

As a technique, s-c-r makes sense only if the component strings are
mutable and the running time of string-set! is O(1).  These conditions
no longer apply in many Schemes, and definitely don't apply to texts.
So either flush the whole thing, or at least flush the optional arguments,
or failing either of these, require the final-string argument to be a
string and not a textual.  SRFI 130 should have flushed the whole thing,
because although it doesn't require mutation, it *assumes* mutation.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
What asininity could I have uttered that they applaud me thus?
        --Phocion, Greek orator