Thank you for these constructive comments.

I'll summarise my views by kind of change:

... wording changes:

Most of these I find very good and I thank you for writing them.  I will
seek more conciseness at some points, but overall, I'm going to include
the changes in abstract and rationale.

... dropping this and that:

I would like to include routines that are likely to be rewritten every
now and then by programmers using hash tables.  In principle, we could
split the "core routines" and the "library routines" in different
SRFI's is we want to be puristic, but I think it's not worth the added
trouble.  So I'm not going to drop any function just because it does not
make programs more portable -- it should also be too marginal for common
use to be dropped.

That said, I could drop the constructor shorthands in favor of
documenting the correct arguments to make a numeric hash table and so
on.  Maybe I should include an examples section.

> Drop size-hint.  Size-hint may be ignored as currently specified, thus its
> status as an optional argument to hash table constructors does nothing to
> make efficient use of hash tables portable.  Allow implementations to
> extend the parameters arbitrarily to make implementation specific
> improvements.

Maybe this is a good approach.  There will obviously be demand for
implementation-specific extensions in the constructor.

> From the document:
>    If some key occurs multiple times in alist, it is unspecified which
>    of the corresponding values will end up in hash-table.
> Why not specify that they are added in the order they appear in the alist,
> such as MzScheme does.  If this is not the case, portable programs can't
> rely on this function unless it is never the case that a key appears twice
> in the alist.  Is there something gained from this being unspecified that
> outweighs the loss in portability?  There is no external syntax for hash
> tables so it seems to read and write hash tables portably one needs a well
> specified alist->hash-table and hash-table->alist.

This is a complicated issue.  My implementation currently adds the value
from the _last_ association in the list, which is probably what you mean
ty "added in the order they appear".  But because assoc&friends returns
the first occurrence, picking the first value would make the API more
consistent with alists.  OTOH, most times I've seen alists with
duplicate keys, it has been as a result of a programming error.  And I
can't think of a situation where the user would _want_ the
implementation to pick the value from the last association of the list
into the hash table.  So, does anybody have experience about what kind
of stuff are duplicate-key alists used for?

... technical issues:

Caveats similar to MzScheme's apply to these hash tables, too.  I could
also elaborate what kind of "unpredictability" is caused by in-place
mutation of keys.  This kind of caveat applies to every equality
predicate, not only equal? -- even eq?, unless somebody can find a place
in R5RS that explicitly says that an object's eq?-uivalence is preserved
when it is mutated in-place.

And then this:
> Also note that the current specification is not correct:
>    Procedure: hash-table-ref/default hash-table key default -> value
>    Equivalent to (hash-table-ref hash-table key (lambda () default)).

Depends on what your definition of "equivalent" is.  You took "default"
to be a syntactic metavariable, while I took it to be a variable.  Maybe
I should simply say "evaluates to" instead of "equivalent to".

Panu

--
personal contact: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/