SRFI 128 specifies of all three of the eq-, eqv-, and equal-comparators that they all use the default-hash procedure as their hash function. This means the eq-comparator can be no more discerning at the hash stage than the equal-comparator, even though many implementations should be able to provide a 'real' eq-comparator hash function that just converts the (tagged) pointer of whatever it’s called on into an exact Scheme integer. This has the bizarre result that hashing something with the eq- and eqv-comparators is required by the spec to have worse performance than actually doing a comparison with the eq? or eqv? procedures, since eq? and eqv? will never recurse into list structures or compare symbols and strings character-by-character.

While *allowing* those comparators to all have the same hash function allows SRFI 128 to be portable to R7RS small, it seems a mistake to *require* it.

I hope this can be fixed with a post-finalization note relaxing the requirement for all three to use default-hash to merely *permitting* all three to use default-hash; otherwise I'd be happy to give up my reservation on the SRFI number 228 for a do-over of this SRFI incorporating this change, plus maybe SRFI 162, and the procedures I had in mind for that stand-alone SRFI anyway.

Daphne