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.

A portable srfi-146 implementation can just choose to make it an error.

This is less useful than guaranteed ordering of comparators, but I feel that alone would consists another srfi. 

On Mon, Jul 17, 2017 at 9:48 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
After having thought of this a bit more, I understand why this proposal is desirable. If we make mappings/hashmaps unequal when they don't share a comparator, however, this would clash with the proposed extension of ’=?’, wouldn't it? An extended version ’=?’ could report the equality of two mappings while the mapping comparator would yield ‘#f’. I think, we have to agree on one semantics.

P.S.: Implementing a mapping comparator that is able to deal with mappings with different comparators is difficult, however, because we would need an ordering (or good hashmap) on comparators.

Unfortunately, SRFI 128 does not define an ordering on comparators. We could use the default comparator of SRFI 128 to compare comparators but the sample implementation of SRFI 128 compares any two comparators as equal.

So what we can do is the following: Extend SRFI 146 so that it allows mappings with different comparators to be compared whenever the underlying SRFI 128 implementation defines a sensible comparator comparator in its default comparator.

We can then ask for a post-finalization note that implementers are strongly encouraged to implement a comparator comparator with a sensible equality predicate (based on eq? or based on equality of the comparator's parts). We can then hope that such an amendment is voted into R7RS-large together with SRFI 146.

When comparators are comparared using eq?, a portable implementation would be possible by using a global counter to give comparators a unique, orderable and hashable identity.

--

Marc
 
 
--

Marc


For make-mapping-comparator, we would also have to define a total order on the set of key-comparators involved so that the comparator returned by make-mapping-comparator is able to provide an ordering predicate.

How could we do this?

We can leave it to each implementation; some rejects it, and some may handle it gracefully.  The proposed suggestion is mostly relevant to hashmaps, but if we do adopt it for hashmaps, we might want to keep symmetry with mappings, too.