First couple of comments on the latest draft:

- Provide constructors in two versions: one that creates a hash table
with insertion-order and one that creates a hash table with no
particular order (e.g., the first version can be distinguished by
adding "/ordered"). This will allow implementations to choose the most
efficient implementation now and in the future, but will place no
burden on implementations in general because they can also forward all
calls of non-ordered constructors to the ordered versions. Moreover,
it helps document the programmer's intent faithfully. Finally, this
will make SRFI 250 a faithful replacement (and extension) of the prior
hash table SRFIs.

- Restore "hash-table-keys/-values/-entries" (in their R6RS versions).
Cursors are no substitute (and hash-table-copy may be too heavyweight)
when the hash table needs to be modified during looping over its
entries.

- The procedure "hash-table=" should be renamed to "hash-table=?"
reflecting the most recent conventions in use.

- The following is too strong: "It is an assertion violation if the
equality predicates of hash-table1 and hash-table2 are not the same in
the sense of the eqv? procedure." Regardless of how one views eqv? for
procedures in general, if one of the two equality predicates is
replaced by an eta-expanded/reduced one, no assertion violation should
be raised. Moreover, if one of the equality predicates can be
customised by a parameter and happens to be equivalent (in the
operational sense) to the other one during the lifetime of both hash
tables, say, neither should an assertion violation be raised.

- The ordered fold procedures could take more than one ordered hash
table, bringing them in line with vector and list folds.

- hash-table-fold is not really a fold (the same misnomer persists in
other unordered contexts); Maybe we can find some better name. Also,
as only one container can be involved in unordered contexts, allow an
arbitrary number of seeds (so that the procedure called iteratively
can yield more than one value).

Am Mo., 29. Sept. 2025 um 23:49 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> I've just published draft #4 of SRFI 250. It was submitted by Daphne Preston-Kendal, co-author of the SRFI.
>
> Here are Daphne's comments on the draft:
>
> Add examples
> Specify error conditions
> Add R6RS library name hash-tables
> Add hash-table-add! and hash-table-replace!
> Add hash-table-cursor-for-key and hash-table-cursor-value-set!
> Remove hash-table-entries, hash-table-keys, hash-table-values, hash-table-entry-vectors, hash-table-key-vector, hash-table-value-vector for being useless, and trivially implementable in terms of hash table cursors if anyone does need them
> General editorial and structural improvements
> Include sample implementation in the repository
>
> Here is the commit summary:
>
> Add Daphne as co-author.
> Commit sample implementation and various updates
> Fix all outstanding spec issues; other major improvements
> Sample implementation improvements
> Tested and corrected all examples. Support immutability
> Improvements
> Add (srfi :250) library
> Markup validation fix
> Remove obsolete sentence
> Remove another obsolete sentence
> Remove unused import
> Add prelude for Guile
> Make Guile prelude declarative and pure
> Note the existing tunings
> Refactor and add helpful debugging information to Guile printer
> Minor optimization in the R6RS compact array implementation
> Further small optimizations
> Remove useless check for an unfilled entry
> Cache the number of entries at which the compact index has to grow
> Remove error checks from compact array implementations
> Fix broken link.
> Publish fourth draft.
>
> Here's the diff:
>
> https://github.com/scheme-requests-for-implementation/srfi-250/compare/draft-3..draft-4
>
> Daphne has asked me to announce last call for this SRFI. She believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.
>
> In particular, I appeal to anyone reading this to try the sample implementation, run the tests, and send feedback about your results.
>
> If you're interested in this SRFI, please give your feedback via the SRFI 250 mailing list before 2025-10-13. After that, assuming that no major revisions are required, we will declare it final. It is important that we get your feedback before 2025-10-13. If that deadline is too soon for you, but you would like to contribute, please let me know so that I can extend the last-call period.
>
> Regards,
>
> SRFI Editor