Taylan Ulrich Bayırlı/Kammer scripsit:

> On the meanwhile I also scrapped the weird overloaded semantics for
> hashtable-ref and separated them into hashtable-lookup (replacing the
> old hashtable-lookup that used to take procedures to call; now it just
> returns those two result/found? values).  I would nevertheless be
> interested in people's comments on the "weird overloaded semantics" so
> I'll wait a bit before making a pull request for draft #2.

I grabbed the version at github.io this morning, so these remarks are
relative to that.

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.

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.

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

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.

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

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.  Likewise,
say that default-proc for -intern! is called with zero arguments.
(I may adopt your older versions of -lookup and -intern! for SRFI 125.)

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

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.

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

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
It's like if you meet an really old, really rich guy covered in liver
spots and breathing with an oxygen tank, and you say, "I want to be
rich, too, so I'm going to start walking with a cane and I'm going to
act crotchety and I'm going to get liver disease. --Wil Shipley