Per Bothner wrote:

> Let me try again.  R^RS/R7RS effectively have this type hierarchy:
>
> string
> - immutable strings (string-set! throws exception)
> - mutable strings (string-set! allowed - need not be O(1)))
>
> For R7RS-large I'm proposing a extension/modification:
>
> string
> - immutable strings (string-set! throws exception)
>    - SRFI-135 text - guaranteed O(1) string-ref
>    - possibly other immutable strings (e.g. java.lang.String on JVM)
>      (However, a pure portable R7RS-large would not use such strings)
> - mutable strings (string-set! allowed - need not be O(1)))
>
> Once we have this hierarchy, we can discuss naming conventions:

SRFI 135 already gives you that hierarchy, regardless of what
WG2 does, so this discussion is entirely about naming conventions.

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.

Whether other kinds of immutable strings should be considered as a
subtype of immutable texts is debatable.  I think it would make more
sense for java.lang.String to be a subtype of textual instead of text,
because java.lang.String doesn't support O(1) access for character
indexes, which is an important property of immutable texts as proposed
by SRFI 135.

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

> We need a different type, with possibly different operations,
> but that doesn't prevent 'text' (or whatever we call it) from being
> a subtype of a 'string' type.

That's just a naming convention/preference.  You could just as well
say it doesn't prevent 'text' (or whatever we call it) from being a
subtype of a 'textual' type.

Will