I think the best way to understand mutable-length strings (MLS) using the location model is that the current length is itself stored in a location. When you append or insert to an MLS, you change the length location, which creates new locations which can then be assigned to, removes existing locations, or both. In that way, it is clear that an empty MLS can be extended, and that two separately created empty MLSes cannot be the same in the sense of eqv?, though they are the same in the sense of equal?.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
Pour moi, les villes du Silmarillion ont plus de réalité que Babylone.
--Christopher Tolkien, as interviewed by Le Monde

On Sun, Apr 5, 2020 at 7:51 PM Shiro Kawai <xxxxxx@gmail.com> wrote:

I understand your reasoning. My question is how to treat the possible discrepancy between R7RS model and yours.
It's ok to introduce a new model (string as a location), but then it'd be nice that it is stated clearly.

Specifically, in R7RS 3.4, "empty string" can be understood not only a literal empty string but also any zero length string. Based on that interpretation, an implementation may return singleton instance for procedures that return a zero-length string (even the spec says it returns "newly allocated copy", there's nothing to copy for zero-length string based on the storage-per-character model, so nothing to allocate newly.)

If a srfi doesn't allow that interpretation, I suggest that to be noted explicitly.

On Sun, Apr 5, 2020 at 1:41 PM Per Bothner <xxxxxx@bothner.com> wrote:
On 2/24/20 2:00 PM, Shiro Kawai wrote:
> Literal empty string is immutable, off course. What I meant by "empty string" is something that's returned from (string-copy "abc" 0 0) or even, (string-copy "").

I'm not sure what you're asking or who you're asking.

In srfi-140, (string-copy "") returns an fresh zero-length mutable string.
This is a valid argument to string-append! and string-replace!.
It is not an "empty string" in the R7RS "3.4 storage model" sense.

The following is valid:

(define w (string-copy ""))
(string-append! w "abc")
(string-append! w "xyz")

Also note (not explicitly specified by srfi-140, but I think implied):

(define s1 (string-copy "))
(define s2 (string-copy s1))
(eqv? s1 s2) => #f
(eqv? s1 "") => #f

I don't think the R7RS concept of a string as consisting of a location
per character is appropriate. Better to view a string as a single location.
Literal strings or other istrings that are equal? may be combined
into a single location, at the discretion of the implementation,
but every mstring must be a unique location.

(In fact, I don't see how the idea of a vector or a pair as consisting of
multiple locations gets you anything useful. The definition of eqv? in 6.1
talks about them having a single location.)
--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/