PS That said, I yet don't see any advantage of SRFI 128's current requirement. The change you propose is probably safe (at least as long as it is understood that the hash function won't, in general, be more efficient than the default hash function).

Am Fr., 16. Juli 2021 um 22:21 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@gmail.com>:
Am Fr., 16. Juli 2021 um 21:46 Uhr schrieb Daphne Preston-Kendal <xxxxxx@nonceword.org>:
On 16 Jul 2021, at 19:17, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

> SRFI 125 allows hash tables to ignore the provided hash function when a predicate finer than `equal?' is used.

And if I want to use the hash function for something else? If the implementation of SRFI 125 is allowed to peek behind the curtains, why can’t the implementation of SRFI 128? (This isn’t an argument for removing that permission from SRFI 125, which I guess is a useful accommodation for Scheme implementations on runtimes which have pointer-based hash tables but no access to pointer values as numbers.)

> Indeed, for moving garbage collectors, there is not a stable efficient hash function for `eq?' that can be exposed to the user, so it is largely irrelevant what the hash function packaged by `make-eq-comparator' is.

Right, but for non-moving garbage collectors there’s no reason not to provide something better. Hence I suggested implementations should be *allowed* to do something better than use default-hash, which they currently aren’t.

I understand what you mean. But the problem seems deeper. An efficient implementation of SRFI 125 does not look behind the curtains of SRFI 128 but has knowledge of the internals of the Scheme implementation. On the other hand, the sample implementation of the SRFI 146 hashmaps is for eq?-based comparators not very efficient because it uses the default SRFI 128 hash function in this case. With your proposal, it would be more efficient on Schemes that can provide an efficient eq?-based hash function. But, in general, it wouldn't be (and state-of-the-art garbage collectors seem to be all moving).

So either APIs like SRFI 146 hashmaps have to be implemented natively to be efficient for eq?-based comparators, or we need some support for unstable hash "functions".

(Maybe the concept of SRFI 128 comparators shouldn't really apply for equality predicates finer than `equal?'. This seems to be somewhat the point-of-view R6RS takes with it's hashtables.