John Cowan <xxxxxx@mercury.ccil.org> writes:

> The next draft of 125 will be fully backward compatible with SRFI
> 69, except that the implementation will be free to return #f from
> hash-table-hash-function if it has used a different hash function than
> was supplied.  Therefore, please remove the claim that SRFI 125 isn't
> backward compatible with SRFI 69.

Done.

> Names of the form (scheme ...) are reserved for libraries standardized
> in R7RS, so please use another name for your library until and unless
> it gets adopted as part of R7RS-large.

Done.

> "Booleans [etc.] are never stored weakly or ephemerally."  That assumes
> that these are always stored as immediate values, which isn't true in
> all Schemes.  In particular, a small system might allocate characters
> dynamically, which means they can be subject to garbage collection.
> I'd just drop this sentence.

Dropping it entirely is no good.  In abstract terms, all instances of
those types are always alive.  In concrete terms, having an association
for a certain number or character suddenly dropped from your table would
be very irritating; the point of weak tables is that they drop entries
only when the entry cannot possibly be useful anymore, which is when its
key or value, assumed to be *uniquely* allocated objects, don't exist in
your program outside the table anymore.  Numbers and characters always
"exist."  Even if as an implementation detail they were deallocated, an
eqv? number or character will be reallocated transparently when needed.

I got the idea from MIT/GNU Scheme, and just realized that it actually
just applies to eqv? hash tables there, which makes sense.  I'll adopt
that.

> Ephemerons are inherently key-weak: I don't think it makes sense to have
> ephemeral-value or ephemeral-value-and-key.  So just use ephemeral-key
> (which could be shortened to ephemeral) and explain that ephemeral tables
> can be used in place of key-weak ones if the implementation sees fit.

See MIT/GNU Scheme.  An ephemeral-value table simply swaps the position
of the key/value in the ephemerons held by the table (but the key is
still the key for the hash table).  In key & value, there is a pair of
ephemerons.

(I just noticed that my interpretation of key & value ephemeral tables
was wrong though; the key and value effectively hold each other strongly
until *both* have no references to them left from outside the table,
whereas in non-ephemeral weak key & value, the entry is dropped as soon
as either the key or value dies.)

> The formal parameter of hashtable? should be obj, as using hashtable
> implies that it must be a hashtable.

Indeed, this was an error adopted from R6RS.  Fixed.

> I think the failure thunk in -lookup should come before the success
> procedure, and the latter should be optional (as in SRFI 125).  (I realize
> this doesn't matter with the version of -lookup you have now.)  Say
> explicitly that not-found-proc is called with zero arguments.

These are indeed irrelevant now, with the new -lookup.

> Likewise, say that default-proc for -intern! is called with zero
> arguments.

Done.

> To fit better with R7RS, change "unspecified values" to "an unspecified
> value" in -clear.

I really wish R7RS had not reverted that change but anyhow, since this
is for R7RS, you're right.

(I also wish it were the norm that "unspecified return value" procedures
would consistently return zero values instead, and non-tail
continuations in bodies errored on non-zero values.  Disabling both
would be an optimization.  But I don't expect this to catch on any time
soon since I haven't heard of it anywhere else, despite that I know it
leads to bugs, even from my limited experience with Scheme code-bases.)

> I think that -for-each should be allowed to mutate the value of the
> entry it is processing.  That is less potentially confounding than being
> allowed to delete it.

After pondering on this and asking a couple people for their opinion, I
decided to adopt `hashtable-map!` for that use-case instead.

> Hashtable-weakness shouldn't be required to return the same symbol passed
> to make-hashtable, if the two symbols are equivalent in the implementation
> (i.e. weak-key and ephemeral(-key)).

Good idea, done.

Thanks for the comprehensive review!  It was immensely helpful.
Taylan