[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Responses to your comments
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
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.
added, as hash-table-hash-function and
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
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
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
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.
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.
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/