William D Clinger scripsit:

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

These both seem right.

What I am going to do is to treat SRFI 13/130 and SRFI 135 as independent
ballot questions, in the same way that SRFI 1 (potentially mutable
pairs and lists) and SRFI 116 (disjoint fully immutable pairs) are
treated as separate ballot questions.  The difference is that SRFI 135
supports potentially-mutable strings, whereas SRFI 116 does not support
mutable pairs.  People are still free to vote "no library" on either
ballot question, of course.

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

I think the former is better.

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

I missed that.

> I am not going to change text-length and text-ref to accept textuals,

Reasonable.

> Almost.  I propose this friendly amendment:

Accepted!

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

Indeed, we also allow (but do not require) implementations to have just
one empty vector and/or just one empty string, though only a few Schemes
do so (see <http://trac.sacrideo.us/wg/wiki/EmptyStringsVectors>).

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Mos Eisley spaceport.  You will never see a more wretched hive of scum
and villainy --unless you watch the Jerry Springer Show.
        --georgettesworld.com