On Sat, Mar 30, 2019 at 9:48 PM Per Bothner <xxxxxx@bothner.com> wrote:

One thing to note: SRFI 140 allows an implementation to support strings that are
neither istrings (immutable strings with O(1) indexing) nor mstrings (mutable strings).
Specifically, in Kawa a "string" is any object that implements the java.lang.CharSequence
interface, while an istring is gnu.lists.IString and an mstring is gnu.lists.FString.
The standard Java java.lang.String class is a Kawa "string" but neither an istring or mstring.
(It is immutable but does not have O(1) indexing.)

Ah, I see that now. I had understood "istring?" to be true of every immutable string, and

"mstring" to be true of every mutable string, but I see it is not so. Does this mean for example

that StringBuilder (which does implement CharSequence) would not be an acceptable argument

to string-set! etc. in Kawa? (I know that CharSequence does not provide mutator methods,

but it would be possible to allow Scheme string mutators to act on StringBuilders and StringBuffers

as a special case.) Fortunately there are no SRFI-140 functions that require their arguments to be

istrings.

Given this, I would suggest adding "mstring?" and keeping "istring?" or alternatively factoring

"istring?" into "immutable-string?" and "linear-time-string?".

Returning to your previous email:

I think a complete list of procedures that return (mutable) strings in R7RS and that I would propose

for SRFI 140bis would be: number->istring, symbol->istring, istring, istring-upcase, istring-downcase,

istring-foldcase, isubstring, istring-append, list->istring, utf8->istring, vector->istring, istring-map,

read-line->istring, command-line->istrings, environment-variable->istring, environment-variable->istrings.

I agree that this list is discouragingly long. I will think further on other means to get compatibility.

At least one requirement of SRFI 135 is not satisfied by an implementation on top of SRFI 140:

"There is some reasonably small fixed bound on the ratio of storage used by the shared

representation divided by the storage that would be used by an unshared representation",

unless you ensure this by sometimes copying when semantically speaking you could share.

The bound in question is 16 for the sample implementation of SRFI 135.