Am Mo., 23. Sept. 2024 um 12:18 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
> On 23 Sep 2024, at 12:13, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> > wrote: > > >> R7RS Large will probably make weaknesses in collection like this > implementation-specified, so conforming impls will have to document if they > can’t collect symbols. > > > > Has this been discussed already? > > <https://codeberg.org/scheme/r7rs/issues/105> > There has never been a real discussion about that in this thread; it quickly evolved into what PTC mean (and made me studying Will Clinger's paper). What do you precisely mean by "make weaknesses in collection like this"? In any case, the meaning of the prose you suggested at the beginning of that thread must be made precise (and seen to be formalisable) for it to be useful. Just for symbols, it is easy: Specify that symbols have a location holding the string the symbol denotes. Further, specify that eq? has a unique behaviour with symbols: It compares them by name equality and not by location equality. (The latter actually shows that forcing GC of symbols would theoretically be a wart.) > > Firstly, it doesn't make sense to use keys without locations, as I tried > to explain. Secondly, SRFI 254 does not ban them but leaves it open. > > > > > It is like saying strings are not important for, say, "+". R7RS leaves > it open what happens when you evaluate (+ 1 "zwei"). > > > The difference between that case and this is that R7RS also clearly states > a set of values for which the result of + is not ‘left open’. > Yes, and SRFI 254 clearly states a set of values that can be used as weak keys. > I still fail to understand in what sense it is not strong enough. It > lists types that are guaranteed to denote locations or sequences of > locations. What else would be needed? > > The list is non-exhaustive. It says ‘such as’. Clearly, there are > ‘objects’ which do not denote locations. > Sure. It would be a mistake if SRFI 254 wanted to determine what denotes a location, what does not denote a location and where it is implementation-dependent. That is an integral part of the core semantics of Scheme, defined in the revised reports. SRFI 254 works with R6RS as it does work with R7RS as it would work with a potential R8RS. Think of it as a template if you want to view it this way. So, it will also work with a potential future report where symbols denote locations (although the comment above leads me to think that it would be wrong to let symbols denote locations). Only if there are useful problems that cannot be solved with the current state of specification of what denotes locations, SRFI 254 has to be amended in such a direction. But we haven't yet seen such a problem or a problem that cannot be solved easily with what SRFI 254 and RnRS already offer.
