Takashi Kato <xxxxxx@ymail.com> writes:

>> 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.

Indeed, as the new wording says, groups of weakly stored objects
referring to each other in a cycle can be reclaimed when there's no
non-weak references to any of them.

(A more accurate description of garbage collector behavior would explain
how tracing references works, but that would have probably been more
difficult to word.)

>> 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?

B might hold non-weak references to the keys, but since it doesn't hold
non-weak references to the values, the values will be reclaimed, which
will lead to the entries with those values being deleted from both A and
B, and so the keys can be reclaimed too.

(In this explanation it sounds like the keys would be reclaimed by a
second run of the GC, but since we don't specify when and how many times
the GC runs, it may reclaim the keys immediately too.  In the real
behavior of a tracing GC, it could reclaim them in one sweep anyway.)

> 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.

Hmm, good question.  Strictly speaking it's fine, because a list is
implicitly "plural" (a collection, at least).

I also see a third option:

- hashtable-key-list
- hashtable-keys-list
- hashtable-keys->list

The last one makes it very obvious that the semantics is basically
(vector->list (hashtable-keys)), and is consistent with
hashtable-map->list.

What do others think?

> - 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).

Make-eq-hashtable clearly states that 'weakness' may be any of:
weak-key, weak-value, weak-key-and-value, ephemeral-key,
ephemeral-value, and ephemeral-key-and-value.  Nowhere is it said that
any of these may be unsupported, except that weak-key and weak-value can
be implemented as the (strictly superior) ephemeral-key and
ephemeral-value.

That being said, I wouldn't be surprised if some implementations start
supporting this SRFI part-by-part.  Likely, some de-facto partitionings
of the SRFI will emerge, like not supporting ephemerals at first, or not
supporting the read syntax at first.  If the SRFI is successful at all,
that is.  I know the strict line of thinking is that a standard is
useless if not adopted in full, but clearly there are very useful
components of this SRFI which don't absolutely depend on each other.

I'm thinking of making weakness optional altogether.

> Cheers,

Thanks again for the input!
Taylan