This page is part of the web mail archives of SRFI 69 from before July 7th, 2015. The new archives for SRFI 69 contain all messages, not just those from before July 7th, 2015.
Hello, I was on a holiday and found my SRFI added with many comments when I came back. I'll try to address your various points in this mail. I'll post something about the more controversial ones in a separate mail. SRFI-44 compatibility: I looked at the applicable parts of SRFI-44 (map API) and didn't like it. However, if an implementation should want to give a SRFI-44 interface to SRFI-69 hash tables, it is easy enough to do so. The way of doing so is sufficiently defined in SRFI-44, so I won't bother with that. hash-table-get, -put!, -remove!: These are provided as compatibility procedures to ease porting of non-SRFI-69 code onto SRFI-69? If you think this is not a worthwhile goal, I can purge them from the SRFI. -ref, -set!, -delete! are IMO clearly better but less used. I added a "don't use this" note to the compatibility versions. hash-table-update!: added. hash-table-copy: added. introspection: added, as hash-table-hash-function and hash-table-comparison-function. order independence of -keys and -values: This is not because of prospective performance merits, but to discourage bad programming style. If one wants to process the association pairs of a hash table, one should not be using -keys and -values. many hash-related enhancements: I think it would make sense to provide a separate SRFI for hashing. The hash functions provided in SRFI-69 are the bare minimum needed by the hash table types supported by it. -size vs. -count: I associate hash-table-size with the actual size of the hash table, so I thought -count would be more intuitive. However, it seems -size is more consistent with the rest of the world. So I changed it. eq? tables: The current SRFI does support eq? hash tables, as (make-hash-table eq?). It should be noted that the optional hash parameter should not be used except when correctness cannot be otherwised guaranteed (as is the case with coarser equality predicates than equal?), or when hashing performance is of utmost importance. hash-table-for-each parameter order: I don't agree that everything ending in -for-each should have a function as the first argument. However, as the feeling for this seems to be strong enough to cause confusion in some, I renamed the procedure into hash-table-walk. list->hash-table etc.: these were renamed to alist->hash-table and hash-table->alist (in accordance with SRFI-1). sizehint is now an optional parameter of alist->hash-table. ht->vector and vector->ht are IMNSHO totally useless and will not be added unless somebody provides a convincing argument for them. Panu -- personal contact: atehwa@xxxxxx, +35841 5323835, +3589 85619369 work contact: pkalliok@xxxxxxxxxxxxxxxx, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/