Shiro Kawai scripsit:

> Initially I thought it would be trivial to replace them with "comparator
> returned by make-eq-comparator" and such,

I decided to simply remove this sentence rather than trying to fix it,
since it's a logical consequence of existing requirements.

> Srfi-128's make-eq-comparator and make-eqv-comparator are specified to use
> the same hash function (default-hash) as make-equal-comparator.  That means
> the hash function is mostly likely to recurse into lists and vectors, so
> mutating the key of hashtables based on the comparators returned by
> make-eq-comparator / make-eqv-comparator can be said unsafe, too.

That's why it only says, or said, "may be possible".  The reason it's
possible at all is that the implementation is free to replace default-hash
in such tables with an implementation-dependent hash function such as
hashing by physical address.

Earlier versions of SRFI 125 simply forbade key mutation, until it was
pointed out that this was too strong a restriction.

> I actually overlooked that during srfi-128 discussion.  Was there a reason
> for make-eq[v]-comparator using default-hash?  It might be inefficient if I
> only want to hash with object identity for eq-hashtable.

It's guaranteed correct, and there is an escape hatch against
inefficiency, but the escape hatch is inherently implementation-dependent.
Providing your own hash function for eq? and eqv? is not guaranteed to
work portably while still maintaining the invariant that if two objects
are equal by the predicate they must hash to the same thing.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
It's like if you meet an really old, really rich guy covered in liver
spots and breathing with an oxygen tank, and you say, "I want to be
rich, too, so I'm going to start walking with a cane and I'm going to
act crotchety and I'm going to get liver disease. --Wil Shipley