Am Fr., 15. Juli 2022 um 01:14 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>:
On Thu, Jul 14, 2022 at 3:52 PM John Cowan <xxxxxx@ccil.org> wrote:
 
The hash functions in the eq-comparator and the eqv-comparator objects are implementation-defined.

That sounds like a fine PFN.  (That's the whole text now, right?)

I think this is much better than the first proposal. It also seems to capture what Daphne had in mind when she started the discussion a few months ago.

It should be noted, though, that not much wouldn't change for Schemes where there is no fast stable hash function (which are probably most Schemes with a fast GC).  For them, a note like the one in SRFI 125 ([1]) is needed, but such a note would probably have to be added to the individual SRFIs using SRFI 128, and not in SRFI 128.

I would also like to point out the discussion on Codeberg ([2]).

Marc

--

[1] - Implementations are permitted to ignore user-specified hash functions in certain circumstances. Specifically, if the equality predicate, whether passed as part of a comparator or explicitly, is more fine-grained (in the sense of R7RS-small section 6.1) than equal?, the implementation is free — indeed, is encouraged — to ignore the user-specified hash function and use something implementation-dependent. This allows the use of addresses as hashes, in which case the keys must be rehashed if they are moved by the garbage collector. Such a hash function is unsafe to use outside the context of implementation-provided hash tables. It can of course be exposed by an implementation as an extension, with suitable warnings against inappropriate uses.)

[2] -- https://codeberg.org/scheme/r7rs/issues/77