Am Sa., 11. Okt. 2025 um 23:32 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> 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.

Three options (all viable in my opinion are possible); the SRFI should
choose one:

(1) One should not use fold-left/fold-right on unordered hash tables
(meaning an implementation SHOULD raise an assertion violation).
(2) One must not use fold-left/fold-right on unordered hash tables
(meaning an implementation MUST raise an assertion violation).
(3) One can use fold-left/fold-right (and cursors) on unordered hash
tables; the chosen ordering will be arbitrary.

If I were to choose, I'd choose option (3). It won't tax
implementations where unordered hash tables have the same underlying
data structure than unordered hash tables.
> > - 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.

The standard R6RS removes possible uncertainty:

"By convention, the names of predicates—procedures that always return
a boolean value—end in “?” when the name contains any letters;
otherwise, the predicate’s name does not end with a question mark."

(This is from Section 6.7, "Naming Conventions".)

Anything going into a future standard should not contradict an
existing one if possible.

> 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 idea is that two equality predicates may be equivalent for when
they are used with hash tables but may never be "eqv?".

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

For example, when you want to "zip" two hash tables where the order matters.

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

hash-table-accumulate would be a better name (although not necessarily
the best).

[...]