Shiro Kawai <xxxxxx@gmail.com> schrieb am Sa., 15. Juli 2017 um 09:25 Uhr:

I realized I can state my argument more simply, without referring to a hashmap of hashmaps.

Comparators can be used just to check equality, without caring ordering. It would be inconvenient if object A and object B both satisfies comparator C's type test predicate, yet (=? C A B) yields an error.

Implementing such an ‘=?’ can be less efficient in case of ordered mappings because the keys in A and B won't necessarily show up in the same order. I don't want to force implementations to have to cope with two cases, namely the fast path when A and B have the same comparator, and the slow path when A and B do not necessarily use the same underlying ordering or hashmap.

Nevertheless, one shouldn't withhold implementations to implement a more general `=?`. So would it suffice if

"It is an error for any procedure defined in this SRFI to be invoked on mappings with distinct comparators (in the sense of eq?)."

were amended by

"However, implementations are free to extend these procedures so that they may also be invoked on mappings with different comparators but with the same type predicate, whenever it makes sense."

On Fri, Jul 14, 2017 at 2:36 AM, Shiro Kawai <xxxxxx@gmail.com> wrote:
On Fri, Jul 14, 2017 at 1:56 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Shiro Kawai <xxxxxx@gmail.com> schrieb am Do., 13. Juli 2017 um 20:48 Uhr:
Current spec restricts mappings or hashmaps can be compared with mapping=? only if they share the same comparators. It is reasonable if we look at the group of submapping procedures as set predicates. However, since mapping=? is also used for the equality predicates of make-mapping-comparator and make-hashmap-comparator, it can be overly restrictive. Especially, it would be useful to allow to create a hashmap of hashmaps which do not share the key comparators (they are not equal.) Also, a mapping of mappings which do not share the key comparators can be created if an implementation defines some ordering in key comparators.

I am not yet convinced about this feature request. I think it is cleaner to use mapping-map/monotone! to coerce mappings to mappings with a common comparator.

Probably it's easier to imagine the use case with hashmap. Suppose you write a memoizing function, and use hashmap to remember past arguments and its computed results. The function needs to accepts various types of objects, but using default-comparator, you can say you can handle arguments of types that can be handled by default-comparator. Since srfi-146 extends default-comparator to mappings and hashmaps, the user can pass hashmaps as arguments, and your memoizing function can map them to the computed result.
However, with the current spec, once the user passes a hashmap, then the user can only pass hashmaps with the same comparator afterwards. Am I right?

And coercing the passed hashmaps to a common comparator doesn't work, for the function may return different results for hashmaps with different comparators.

So the default comparator should be able to compare any two hashmaps.

If we want to allow such heterogeneous mapping-of-mappings / hashmap-of-hashmaps, we could either:

1. Loosen mapping=? to allow mappings/hashmaps of different key-comparators (they are not equal)
2. Define make-mapping-comparator/make-hashmap-comparator such that its equality predicate returns #f if given mappings/hashmaps don't share the comparator, and obey mapping=?/hashmap=? otherwise.

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.

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.