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/