On 06/07/2016 06:51 PM, William D Clinger wrote:
> SRFI 135 already gives you that hierarchy, regardless of what
> WG2 does, so this discussion is entirely about naming conventions.

Mostly.  I also propose that string literals (and other immutable
strings in R7RS-large) have type text.   I,e, (text? "foo") => #t.

> Let's suppose we rename all of the SRFI 135 operations that accept
> both strings and texts so they start with "textual-" instead of the
> ones that currently start with "text-".  Then we have a hierarchy
> isomorphic to what you wrote above:
>
> textual, comprising
>   - immutable texts (string-set! throws exception, O(1) access)
>   - mutable strings (string-set! allowed, might not be O(1))
>
> textual?, textual-length, textual-ref, and all of the other operations
> whose names (would) start with "textual-" accept any argument of type
> textual.  Of those operations, the ones that return textual results
> would return immutable texts, so you'd have to call one of the "string-"
> procedures if you wanted to get a mutable string back, but that's okay;
> calling a "string-" procedure would be an effective way of marking the
> calls in your code that are intended to produce a mutable string.

I'm proposing classifying the procedures in this SRFI into two categories:

(1) Ones that returns a text; or a list/vector of text (i.e. text-split); plus text? :
These should retain the text- prefix (or some alternative new prefix,
such as istring- or fstring-).

(2) All the other ones should be renamed string-xxx.  This assumes no conflict
with existing (or proposed) string- procedures; if there are conflicts they
should be considered on a case-by-case basis.

>> The SRFI-135 uses 'textual' for the common supertype of 'string' and 'text'.
>> I suggest using 'string' for this common supertype, as that matches past history
>> better IMO.
>
> Historically, Scheme strings were mutable and provided O(1) access.
> We already seem to have given up on the latter.  I don't see how
> giving up on the former as well helps to preserve past history.

I meant in the sense of fewer modifications to existing
code needed, as well as being able to re-use the existing and well-established
'string' name - which we can't remove regardless.

--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/