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:
* For =? to work, you don't need to order or hash comparators.
* 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.)

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:

    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,
    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.

How about that?

  


On Thu, Jul 20, 2017 at 4:23 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
Please review the changes here: https://github.com/mnieper/srfi-146

--

Marc

Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> schrieb am Do., 20. Juli 2017 um 15:58 Uhr:
Shiro Kawai <xxxxxx@gmail.com> schrieb am Di., 18. Juli 2017 um 13:29 Uhr:
For the scope of srfi-146, an implementation can compare given mappings' comparators directly by its own specific way, so I'm not sure it's worth to involve srfi-128.  How about something like this:

When {mappings|hashmaps} with different comparators are compared, it is an error if the implementation doesn't provide {an ordering predicate|a hash function} for comparators.  If an implementation's default comparator can {order|hash} comparators, it is used for {ordering mappings|hashing hashmaps}.  When ordering mappings, they are ordered first by their comparators, then within each group of shared comparators, they are ordered lexicographically with respect to the keys.  If an implementation's default comparator doesn't handle comparators, an impelentation of srfi-146 may still provide its own ordering of comparators.


I think, we have to be a bit more careful here. The default comparator implementation of SRFI 128 does actually supports comparators. But the equality predicate is trivial. So, we would have to ask whether the default comparator uses eq? for equality of comparators.

But then, it would work.

Shiro Kawai <xxxxxx@gmail.com> schrieb am Di., 18. Juli 2017 um 20:50 Uhr:
Right.  What I specifically request is a guarantee that this works for mappings A and B which doesn't share the comparator (and returns #f in that case):

   (=? mapping-comparator A B)

When we agree on "eq?" above, it makes sense to demand that "=?" always returns "#f" if A and B do not share the same comparator. And this has nothing to do with whether the implementation can order comparators using "eq?" as the equality or not, but can be portably implemented.

Marc