On Sun, Jul 23, 2017 at 4:43 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

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.

Oh, I read it as the behavior of default comparator comparing key comparators, because it first talks about comparing comparators, then goes as "doesn't provide a *compatible* ordering procedure or hash function, respectively" (emphasis mine), so this phrase appears to refer to the compatible ordering/hash for comparator comparison. The ordering/hash procedure for value comparator is already referred to in the preceding paragraph, so I don't think we need to repeat that.

It's confusing, so let's draw out a call graph:

(make-mapping-comparator value-comparator)

- equivalence pred

--- impl.dependent comparator-comparator (*)

--- impl.dependend comparator equivalence pred

--- value-comparator

--- value-comparator equivalence pred

- ordering procedure

--- mapping's key comparator (if key comparators don't match, error)

--- mappings' key comparator's ordering procedure

--- value-comparator (for values)

--- value-comparator's ordering procedure

(make-hashmap-comparator value-comparator)

- equivalence pred

--- impl.dependent comparator-comparator (*)

--- impl.dependend comparator equivalence pred

--- value-comparator (for values)

--- value-comparator equivalence pred to compare values

- hash function

--- impl.dependent comparator hash function (*) (optional**)

--- key comparator's hash function to hash keys

--- value-comparator's hash function

So, if you're talking about comparing comparators (*), it needs neither ordering procedure nor hash function, and no point to mention that

(although it's better to have hash function in (**) case).

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?".

The "Comparator restrictions" section mainly talks about value comparators, so probably it's better to make it clear that comparing comparators is a different topic. How about something like this:

"The procedures in Submappings and Set-theory opertaions, and the comparator of mappings described in Comparators section, may deal with multiple mappings. Unless otherwise noted, it is an error to pass mappings with different key comparators w.r.t. implementation dependend equality predicate, which is at least as fine as "equal?"."

And note the exception in mapping=? and equivalence predicate of make-mapping-comparator section that different key comparator yields #f for equivalence predicate.

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.

Right. It's good to note that.

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?

I think it should. It's important that users can count on it.