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