Am So., 22. Sept. 2024 um 12:36 Uhr schrieb Daphne Preston-Kendal < d...@nonceword.org>:
In the Scheme parallel version of this, strings are mutable, so I have two > options: 1. pretend they’re not mutable and make the behaviour undefined if > someone mutates a string which has been used with the C regexp library; 2. > add an extra layer of indirection and intern all the strings with > string->symbol, and put those in my weak/guardian mapping instead. > Symbols do not denote locations in general, so you wouldn't be able to use symbols as weak keys. It wouldn't make much sense anyway because you can always recreate a symbol using `string->symbol`, so it would make most sense logically for an implementation to never invalidate symbols as weak keys. However, in practice, implementations do. In any case, symbols as weak keys do not make sense logically. Regardless what I choose, both options potentially break with a blanket > implementation-dependent ban on ephemeron/guardian keys without location. > The empty string does not necessarily have location, so I would have to > special case that for portable code. 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. > Literal strings which are small enough to fit in a uintptr with a tag > might also not have location (though I don’t know any current > implementation that does this). Non-empty strings do have locations by 3.4 of R7RS. This is why I insisted on the word "partially". > But this is, as I mentioned in my previous mail, already the case for > symbols with short names in some Scheme implementations, so that strategy > would require even more care. > As described above, strategy 2. wouldn't work reliably anyway (and you would have to copy every string because the modification of a string after it has been interned is an error). I don't see how the string mutation problem is linked with SRFI 254. I would also say that weak tables with ephemerons are not the right tool for the mapping problem. You really would like to have an equal?-based table, not an eq?-based table. If all your strings are string literals, you have more chances with an eq?-based table, but then you better write a macro that turns your string into a regexp or whatever. And if your strings are constructed during runtime, eq?-based tables won't help. A solution is an equal?-based hash table with a limited capacity and some caching mechanism. (Some future SRFI may specify an API for caches.) Marc
