After talking with Mark Weaver on IRC I decided to do some renames.  His
input was in line with input I had also gotten from Taylor Campbell a
while ago: it's bad to expose any operations with nondeterministic order
of applications/results.  Radical solutions involve 1. dropping such
operations entirely or keeping them very minimal, 2. specifying ordered
hash tables like in PyPy.  But these are obviously very radical.  If
anyone knows a good solution, please share.

For now, I just try to make the API's pitfalls more open to sight via
different names for some operations.  There's also the secondary reason
that I've deviated from typical argument order for operations in the
for-each and map family.

***

Here's the renames and their rationale:

- hashtable-for-each -> hashtable-walk

Two reasons: the argument order is now different from a typical
for-each, and more importantly, a for-each operation typically does its
applications in a well-specified order, whereas this one does them in
unspecified order.

Actually "walk" does sound like it has an order, so I'm open to even
better suggestions.

- hashtable-map! -> hashtable-update-all!

Again, argument order for one, and different semantics for two.
"Update-all!" also makes the semantics very clear in analogy to the
singular "update!" operation.

- hashtable-fold -> hashtable-sum

Once again, argument order for one, and more importantly different
semantics.  "Sum" is a good name because it makes it obvious that the
given procedure should be associative and commutative in a sense.

- hashtable-map->list -> hashtable-map->lset

The resulting list should be treated as a set.

Semantically this goes very well with its implementation in terms of
hashtable-sum, where the consing up of the result list can be considered
associative and commutative because at every application it takes the
union of the so-far accumulated set and the one-element set of the
current result; set-union is an associative and commutative operation.

***

To a casual onlooker, all this might seem extremely pedantic.  But I
could not possibly ignore the advice of two very experienced Schemers,
especially combined together.  The best way to go actually is probably
to reduce one's use of traditional hash tables altogether (Mark's
position), because they're inherently imperative, but I hope that these
names offer an intermediate solution.

Taylan