Does this all mean that non-empty strings are required to work as keys?

What about symbols? (I admit the use cases for these are a bit tenuous.) The R7RS is actually silent on whether these have ‘location’ in the specialized report sense or not. (‘Such as’ is a non-exclusive list.)

This needs a stronger definition of what has ‘location’ and what not than R7RS small provides. Also stronger than R6RS’s, to my knowledge.

Daphne

On 22 Sep 2024, at 14:02, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

> Am So., 22. Sept. 2024 um 13:55 Uhr schrieb Daphne Preston-Kendal <xxxxxx@nonceword.org>:
> On 22 Sep 2024, at 13:42, Marc Nieper-Wißkirchen <xxxxxx@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.)
>
> In the document, I use the language "location or sequences of locations".  (Should I have missed it at some particular point, please tell me so that I can correct it.)
>   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.
>
> When the spec of SRFI 254 uses the term "location", it does, of course, refer to the technical term as defined in the revised report.  How locations (and if) are represented in the machine by the implementation is outside the scope of SRFI 254.
>  Marc
>