On 07/17/2016 02:20 PM, Jim Rees wrote:
> So there's a vote deadline approaching soon, and before I consider changing my vote, I'd like to better understand what this option entails.
>
> I think the core ideas here are:
>
>    - that literals and the result of symbol->string are istrings with O(1) string-ref,  possibly some cool sharing features, and possibly an exception raised when any mutating operation is attempted.

Yes - though I would say an implementation SHOULD (in the RFC 2119 sense)
raise an exception when any mutating operation is attempted.

>    - istrings and mutable strings are both strings.    All procedures that operate on strings accept both kinds of strings.

Yes - assuming you don't attempt mutation, of course.

>    - the document mentions SRFI-118 is included -- so I infer this to mean that all mutable strings support extension with string-append! and arbitrary resizing with string-replace!.

SRFI-118 is rather orthogonal.  However, as I wrote in SRFI-118 I feel that mutable
fixed-sizes strings (and string-set!) are useless except to implement some higher-level
abstraction (such as an append-buffer).  Hence one might as well specify more useful
procedures (string-replace! and string-append!), since they're trivial for most
implementations to implement, and the functionality is basically required internally
for any implementation that uses UTF-8 or UTF-16 strings.

>    - that many (virtually all) of the interesting string-producing procedures from R7RS (scheme base) and (SRFI 13) *are re-defined and re-exported here to return istrings*.
>
> This is the gist of it, right?

Yes.

> A vote for (SRFI 140) is one that rocks the boat a bit (for the better), while (SRFI 135) is the "safe path" to immutable strings, while risking the possibility that it won't catch on because old code doesn't require updating, and I don't have keys on my keyboard for « and ». ;-)

Exactly.  Well put.

> ---------------------------
> Aside, just more thoughts on this SRFI,
>
> If the presumed default behavior of string-producing API is now to return istrings, it seems like more effort should be spent detailing all the ways to construct mutable strings, and I can only contemplate a few such procedures:
>
> (make-string len [ fill ])
>
> Since SRFI-118 is implied, then make-string could be permitted to accept 0 arguments, returning a zero-sized mutable/extendable string.  I think make-string should be reserved to construct mutable strings only.   If the desire to create a filled istring is there, consider adding make-istring, or make-filled-istring.

What about (string-repeat N S) or (string-repeat S N), where S is either a string
or a character?  Does either procedure conflict with any prior art?

> (string-copy string [ start ] [ end ])
>
> ...since substring could now be presumed to return an immutable string always, string-copy might as well be reserved to build mutable strings.

Agreed - and the specification makes that recommendation.

> SRFI-13 includes substring/shared.   Would you imagine having this, when given a mutable string as an argument, return a mutable string as a result referencing shared storage

Mutable shared strings can be useful.  Consider an Emacs buffer as a string.
Then a substring is the area between two markers in the buffer.  However, that's
a more heavy-duty data structure.  It's unclear whether it belongs in a core
language library, nor is it clear whether *all* mutable strings should support markers
(or equivalently shared substrings).  It may be worth considering in a world where
most strings are istrings, so we only have to support markers on mutable strings.

Regardless, I'm not proposing any kind of shared substrings at this point.
But note this SRFI does not preclude an implementation (or a future standard) from
adding "buffer" as another subtype of string - or even the normal mutable kind of string.

It could be useful to have a kind of immutable shared substring that knows
the arguments used to construct it - i.e. base string and start/end indexes.
This could use useful as the result of a search procedure, for example.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/