I propose to do is to change the names of all SRFI 135 procedures
that accept accept textuals (both strings and texts) from text-*
to textual-*.

I do not propose to change the name of subtext, because its
performance on texts is critical and there is already an alternative
(text-copy, to be renamed textual-copy) that accepts strings as well
as texts.  I will, however, add a subtextual procedure that accepts
strings as well as immutable texts.

John Cowan wrote:

> Suggestions:
>
> Explicitly allow objects other than texts and strings to be textuals,
> both in the definition of textuals and in the description of textual?.

That's fine.  In the portable sample implementations, however, the only
textuals will be strings and immutable texts.

Also:  Implementations that extend textual? to be true of things other
than strings and immutable texts must also extend all of the procedures
whose names being with "textual-" to accept those other things as
arguments.

> Allow text-null?, text-length, and text-ref to accept textuals, and note
> that the guaranteed O(1) behavior applies only to texts.

I don't have any problem with changing text-null? to textual-null?
or with adding textual-null? in addition to text-null?.

The current draft of SRFI 135 already includes textual-length and
textual-ref in addition to text-length and text-ref.

I am not going to change text-length and text-ref to accept textuals,
because that would make them redundant with textual-length and
textual-ref.  The reason for having the text-only text-length and
text-ref is they're simple enough so compilers can generate inline
code for them, or at least inline the common case as is commonly
done for arithmetic operations.

As can be seen from the discussion at the WG2 board, some people
think the efficiency of those basic operations matters.  I'm one
of those people.

> As mentioned earlier, require text-copy to return a newly allocated object.

Almost.  I propose this friendly amendment:

    If the text returned by text-copy is non-empty, then it is not eqv?
    to any previously extant object.  If the text returned by text-copy
    is empty, then it may be eq? or eqv? to the text returned by (text);
    if not, then the result is not eq? or eqv? to any previous object.

    The text returned by text-copy does not share any substructures
    that retain characters or sequences of characters that are
    substructures of its first argument or previously allocated
    objects.

You have to allow the result to share something like a record or
class header with other immutable texts, or you've made the thing
too hard to implement efficiently.

Having just one empty list has worked pretty well, so I think we
should allow implementations to have just one empty text.  The
sample implementations have just one empty text.

Will