The last commit specifically says:
When mappings with different comparators are compared, it is an
error if the implementation's default comparator doesn't compare
comparators using <code>eq?</code> as the equality predicate and
doesn't provide a compatible ordering procedure or hash function, respectively.
(If an implementation's
default comparator doesn't handle comparators, an implementation of
this SRFI may still provide its own ordering of comparators.)
Aside from eq?, I think it is still overspecifying:
What about: "... doesn't compare comparators using an equality predicate at least as fine as <code>equal?</code>..."?
* For =? to work, you don't need to order or hash comparators.
The paragraph you quoted above does not refer to =? but to the comparator returned by make-mapping-comparator.
* For hash function to work on hashmaps, comparators don't need to be hashable (hash function of hashmap can just ignore its comparator, though it's less optimal.)
Any implementation of this SRFI is permitted to soften the restrictions.
Also, are you inclined to allow mapping=? accepts mappings with different comparators? I'm totally fine for it to restrict mappings with the same comparators; I'm concerned only for (=? (make-mapping-comparator value-cmpr) mapping1 mapipng2) case, and we can make explicit mention in the case there, without touching mapping=?. I'm not sure which way is better.
If we allow mapping=? to accept mappings with different comparators and (mapping=? value-cmpr mapping1 mapping2) => #f for such mappings, then the equality test behavior is covered clearly in the paragraph before the added one I quoted, so I think the above quoted paragraph is unnecessary. We only need to menthion ordering case:
We can add the clarifying paragraph to the "Comparator restrictions" section saying that comparators are compared by an implementation dependent equality predicate, which is at least as fine as "equal?".
If <code>make-mapping-comparator</code> is imported from <code>(srfi
146)</code>, the lexicographic ordering with respect to
the keys (and, in case a tiebreak is neccessary, with respect to
the ordering of the values) is used for mappings sharing a comparator.
If its ordering procedure is invoked on mappings that don't share a comparator,
it is an error unless the implementation's default comparator can order comparators,
That ordering has to be compatible with some sensible equality predicate. Note that the sample implementation of SRFI 128 does order comparators albeit trivially.
or the implementation of (srfi 146) provides some way to order comparators.
If the implementation can order comparators, it takes precedence before
the lexicographic ordering.
Plus,
If <code>make-hashmap-comparator</code> is imported from <code>(srfi 146 hash)</code>,
the hash procedure of the returned comparator may use hashmap's key comparator for hash
value calculation, if the implementation's default comparator is capable to hash comparators.
Shall (make-hash-map-comparator) provide a hash function if the implementation's default comparator isn't capable to hash comparators?
Marc