I don't quite recall the context of this thread; but the current srfi-146 looks like:

- It doesn't prohibit making srfi-146 hashmap and srfi-125 hashtable the same thing.

- hashmap-comparator stays, after all (In the srfi-146 document it isn't explicitly listed, but there's mapping-comparator and it implies existence of hashmap-comparator.)

If an implementation chooses to make srfi-125 hashtable the same thing as hashmap, it must use an implementation-dependent way to provide hashmap-comparator, for it can't be implemented portably on top of srfi-125, but it's easy for each implementation to provide it. (Gauche does so: https://github.com/shirok/Gauche/blob/master/lib/srfi-146/hash.scm#L422 ).

And for the portable implementation we have HAMT so it is not an issue (as Marc describes).

So I think the draft #13 is ok.

On Sun, May 20, 2018 at 12:28 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

I'm not sure whether SRFI 125 and SRFI 146 allow hashmaps and hash-tables to be the same as both SRFI 125 and SRFI 146 speak of hashmaps and hash-tables, respectively, being disjoint types, which, by intention, means that they are, in particular, mutually disjoint.

Thus implementing SRFI 146 on top of SRFI 125 forces hashmaps to be at least a thin wrapper over hash-tables. This, in turn, is enough to store the comparator along, allowing to implement hashmap-comparator. What you wouldn't be able to do would be to convert arbitrary hash-tables to hashmaps (without effectively copying the data structure).

Therefore and because of the reasons, Shiro had raised, and because of the fact that a "poor man's" implementation of purely functional hash-maps by hash-tables is not in the spirit of this SRFI, I'm against removing hashmap-comparator. (It probably makes more sense to implement SRFI 125 on top of SRFI 146.)

And, after all, we now have a portable implementation of (srfi 146 hash).

Marc