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.