On Tue, Jul 4, 2017 at 1:56 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

1) It is easy to prefix the procedures in (srfi 146 hash) by hand by using the prefix import modifier of the R7RS library system.

True. However, I like to make it practical to make SRFIs work reasonably well even in down-level implementations.

2) I see (srfi 146) as a fallback for those implementations that do not provide (srfi 146 hash).

I think it's more the other way about: (srfi 146) is strictly more powerful than (srfi 146 hash), unless the keys are absolutely not orderable. What is more, pure updates to hash mappings involve copying the whole hash table, unless you know some clever approach to avoid it; that's why there are none of them in SRFI 125.

If they are in different SRFIs, the existing of such a fallback is not guaranteed.

Guaranteeing things is not SRFI business, but standard business, I think.

3) Most of the functionality provided by (srfi 146 hash) is already in (srfi 125), hash tables. So if we were about to create a new SRFI that is concerned with mappings based on hashing, it should be some kind of unification of (srfi 125) and (srfi 146 hash).

I think that (srfi 146 hash) is already a superset of the non-deprecated parts of (srfi 125), with the exception of hash-table-pop!. I think it would be good to add mapping-pop(!), which returns three values: the first key (or any old key in (srfi 146 hash), the associated value, and a mapping containing all the remaining associations. In that way there is no need to unify, just to implement hashmappings.

If you want to keep both types in the same SRFI, I would still like to have the procedures separated by name. Let us have mapping-* and hashmap(ping)-*, just as we have set-* and bag-* in SRFI 113. I could have called them both sets, and just had (srfi 113) and (srfi 113 multiset), but I didn't, because I thought they were equally important concepts. If that is done, I don't much care if they are in the same library or the same SRFI.