Responses to your comments Panu Kalliokoski (03 May 2005 20:51 UTC)
|
Re: Responses to your comments
bear
(05 May 2005 08:27 UTC)
|
Re: Responses to your comments
Scott G. Miller
(05 May 2005 12:32 UTC)
|
Re: Responses to your comments
Panu Kalliokoski
(06 May 2005 08:44 UTC)
|
Re: Responses to your comments
Sven.Hartrumpf@xxxxxx
(04 Aug 2005 14:22 UTC)
|
Re: Responses to your comments
Panu
(05 Aug 2005 06:57 UTC)
|
Responses to your comments Panu Kalliokoski 03 May 2005 20:51 UTC
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: xxxxxx@iki.fi, +35841 5323835, +3589 85619369 work contact: xxxxxx@ling.helsinki.fi, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/