The thing is, length-changing mutation is diversion from the location-based mutation model--at least in srfi-118, string-append! and string-replace! can't be explained by mutating the value of the original string locations.  It can be explained by introducing an indirection (a string have a single location that points to a location of the storage), but then an empty string can have a location.


On Mon, Feb 24, 2020 at 10:24 AM John Cowan <xxxxxx@ccil.org> wrote:
By definition an empty string (or list or vector) cannot be mutated, because mutating is changing the value of a location, and "", #(), and () have no locations.  What is undefined is the value of (eqv? "" "") and (eqv? #() #()); they can be #t or #f and need not always return the same result.  Of course (eqv? '() '()) is always #t.


On Mon, Feb 24, 2020 at 3:20 PM Shiro Kawai <xxxxxx@gmail.com> wrote:
This is not so much about srfi-185 but more about srfi-118, but are these procedures
allowed to mutate an empty string?

R7RS says "empty strings, ..., which contain no locations, may or may not be newly allocated". Although string-copy etc. are defined to return a newly allocated string, It may return a singleton instance if the result is an empty string.

It might be nice to have a word that, in srfi-185, the caller can safely pass an empty string without worrying the singleton instance is destroyed.