On 22 Sep 2024, at 13:42, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> wrote:
> Non-empty strings do have locations by 3.4 of R7RS. This is why I insisted > on the word "partially". No, that section says: ‘Variables and objects such as pairs, strings, vectors, and bytevectors implicitly denote locations *or* sequences of locations. A string, for example, denotes as many locations as there are characters in the string.’ [emphasis mine] The locations in the string are known by their indices. (This section of the R7RS small document seems somewhat badly written. I will try to do better for Large.) A short immutable string, especially a string literal, does not have to have location in an implementation, and there will be no visible difference to conforming R7RS small code. It simply has to work with string-ref: if someone’s implementation packs short immutable strings into a uintptr, they can use bitwise operations to get the characters out. string-set!, the case where the string itself having location really matters, doesn’t have to work on those strings. > Yes, which is good because the empty string is special; you can possibly > always recreate it, so you have to be explicit whether you want it to stay > forever in your table or not. In cases like this, in practice you’d want to combine finalization based on the GC with finalization based on a generously-sized least-recently-used cache anyway, probably. Even with longer strings that do have location, you don’t want to keep them around forever, because just because it’s still live doesn’t mean someone will ever want to do a regexp operation on it ever again. Daphne
