> Does that answer the question?  Feel free to elaborate.
Yup :)
I was just wondering if more than 1 weak-key hashtable contains the same
key, then it would be a cross reference and GC wouldn't collect it. But
both has weak reference so they should to be collected.

 > If the GC runs first, the stale entries of A are removed and don't
 > even get into B; if the copy runs first, then all entries get into B,
 > but if after that they still don't have any non-weak references to
 > them, they then get collected.
So in this case, if GC runs after the copy, then all entries should
remain until it's removed from B (because B has non-weak reference of
A's keys). Am I correct?

 >> - hashtable-intern!: it would be convenient that default-proc takes
 >>   the key as its argument so that users can derive values from the
 >>   key.
 > In that case they can just let-bind the key (most often it will
 > already be bound to a variable). If the one argument were forced,
 > then users who want to use a nullary procedure would need to wrap it
 > in a lambda to ignore the one argument. Do you have any data or
 > experience on which use-case is more common?
Honestly, haven't got any use-case for this. Only in my mind, this
procedure would be useful to initialise a hashtable so if values
can be derived from keys, then it might be better not to create a
thunk each call.

 > I like this, but do you have any data or experience on how often it's
 > really used?  I'd like to get a bit more input before adding another
 > procedure.
Again, haven't got much experience yet. But I think this can be an
alternative of alist -> alist map since there's alist->hashtable in
this SRFI. One of the reasons why I use alist instead of hashtable is
because of lack of hashtable operation procedures so why not hashtable
-> hashtable?

Other trivial things:
- There's hashtable-keys but the list version is hashtable-key-list
   (without 's'). Is this intentional? The same goes hashtable-values.
- What's the minimum support of <weakness symbol>s? Seems weak-key,
   weak-value, ephemeral-key and ephemeral-value but I'm not sure if
   I'm right (couldn't read it from the SRFI properly).

Cheers,

_/_/
Takashi Kato
E-mail: xxxxxx@ymail.com