If the goal of srfi-146 is to be implementable on top of srfi-125,  hashmap-comparator is the one that prevents hashmap from being the same thing as srfi-125 hashtables.  But in general, I think the introspection of comparators is valuable when you're writing a generic data structures, and the lack of it would drag future libraries to be written on top of srfi-146.  I think I had a bunch of occasions I needed to retrieve comparator from a generic map.

For the implementers, it's probably not much a barrier to add hash-table-comparator natively just to support srfi-146 efficiently.  How important is it to have both (1) srfi-146 on top of existing srfi and (2) allowing hashmap to be hashtable?


On Sun, Sep 10, 2017 at 4:24 PM, John Cowan <xxxxxx@ccil.org> wrote:
After messing around with various other strategies, I have decided (since the SRFI does not forbid it) to make hashmaps and hash tables the same things.  This works fine for every procedure in the SRFI, given that I have no intention of implementating true functional hash tables, and pure hash table operations therefore involve copying the hash table before mutating it.

The exception is hashmap-comparator: there is no way to retrieve the comparator of a SRFI 125 hash table, due to the fact that it may be the same as a SRFI 126, SRFI 69, or native hash table, which have no comparators.  This introspection is probably not often needed anyway, so I would request that mapping-comparator and hashmap-comparator be removed from SRFI 146.

Thanks.

-- 
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Kill Gorgun!  Kill orc-folk!  No other words please Wild Men.  Drive away
bad air and darkness with bright iron!   --Ghan-buri-Ghan

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=rBAxDxCgJFjJUssha9ixdMZU57qO20An