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 <marc.nie...@gmail.com> wrote: > Am So., 22. Sept. 2024 um 13:55 Uhr schrieb Daphne Preston-Kendal > <d...@nonceword.org>: > 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.) > > 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 >
