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.

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.

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.