Am Mi., 18. Sept. 2024 um 17:07 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
> Marcā likhitaḥ: > > > The existing SRFIs 124 and 246 do not say anything about which Scheme > > values are suitable as ephemeron keys and as elements of a guardian. > > > > For example, in Chez Scheme, an ephemeron with a fixnum key is never > > broken; an ephemeron with a bignum key can. (This reflects the > > delicate behaviour of eq? on numbers in Scheme.) > > > > One possible solution is to disallow values which do not refer to > > locations as weak keys. > > I see the sample implementation currently does this. > And the text reflects this by saying that the keys should have locations. This means that you won't see a catastrophic failure, but you have to know what you do (and your implementation of SRFI 254). > I think it is probably a bad idea, because what has location and what > does not is implementation-dependent – beyond matters which, in R6 and > It is partially implementation-dependent, which is an important distinction. The RnRS define a lot of value types that have locations. > in the Large language, are easy to detect, such as fixnum range. Some > implementations store symbols with short names as immediates to relieve > GC pressure. Some implementations don’t have characters as immediates. > Some implementations have a single ‘empty string’ value. (You can > imagine someone maintaining an ephemeron table mapping strings to > some kind of property, even using string->symbol to intern them, and an > empty or very short string ending up in the table.) > Using strings as keys is not a problem because strings denote locations. Symbols as weak keys won't work. In principle, a symbol is always accessible because one can always reconstruct it using string->symbol. Nevertheless, implementations break weak cells holding symbols when the symbol is garbage collected. Likewise, numbers as weak keys do not make sense as well. I proposed a ‘has-location?’ primitive a while ago, exactly for the > purpose of detecting whether it makes sense to put something in an > ephemeron or a guardian, and John Cowan rejected it for basically these > reasons. (Alas, I don’t remember where: it might have been in a private > conversation with him.) > This wouldn't solve the alleged portability problem. The idea of a weak table that can store keys of any type is misguided, in my opinion. By the Scheme semantics, conceptually, a weak key has to be a location. As locations are not first-class objects, we use objects to denote them. Note that transport cell guardians work with any object, and they have to.
