On 11 Oct 2025, at 12:23, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

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

How do you imagine this working in practice? What would hash-table-fold-left and hash-table-fold-right do on hash tables created with the unordered constructors? What would hash-table-cursor-next and hash-table-cursor-previous do? All procedures, I assume, would have to be (ad hoc) polymorphic between two different underlying representations.

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

Okay, this is a credible argument for this. I admittedly can’t think of any cases where you’re changing the *structure* of the hash table during looping (and where you couldn’t just build a new hash table) – note that hash-table-replace! and hash-table-cursor-value-set! are safe during iteration – but sure.

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

Defining ‘recent’ as ‘since R7RS large SRFI development began’, I see no particular strong consensus either way; at most, a tendency:

=: SRFI 116 ‘ilist=’, SRFI 122/179/231 ‘interval=’, SRFI 133 ‘vector=’, SRFI 134 ‘ideque=’

=?: SRFI 125 ‘hash-table=?’, SRFI 127 ‘lseq=?’, SRFI 146 ‘mapping=?’/‘hashmap=?’, SRFI 196 ‘range=?’, SRFI 214 ‘flexvector=?’, SRFI 225 ‘dict=?’

I haven’t seen anyone explain why SRFI 125 changed the practice to =? for collections procedures which take an extra comparison procedure argument. It is unfortunate that we ended up with this split; I can only assume it’s by accident as the authors of some SRFI at some point didn’t realize the difference in convention. I think future revisions of SRFIs which added question marks should revert to the practice established (afaik) by Olin in SRFI 1.

Also: SRFI 224 calls its ‘fxmapping=?’ but the first argument is a comparator, not a procedure, even though it only uses the equality procedure.

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

This is not allowed by R7RS small, I think – well, not in any realistic situation I can think of, anyway? Especially since this is really a proxy for ‘the *comparators* of the two hash tables must be eqv?’, but without having to store the comparator object.

Perhaps you’re right, though, as the carve-out for R6RS feels a bit ugly, depending on implementation-defined behaviour as it does …

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

I don’t understand this.

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

Hmm. True. Can you think of a use for this?

> - hash-table-fold is not really a fold (the same misnomer persists in
> other unordered contexts); Maybe we can find some better name.

Haskell unordered-containers derive Foldable; I’m not too concerned about the theoretical purity of this naming.

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

I don’t understand this suggestion. An unordered fold isn’t guaranteed to be randomly ordered; it only might be.

Daphne