Race condition with compound keys Daphne Preston-Kendal (15 Aug 2025 08:59 UTC)
Re: Race condition with compound keys Marc Nieper-Wißkirchen (15 Aug 2025 15:38 UTC)
Re: Race condition with compound keys Daphne Preston-Kendal (15 Aug 2025 18:33 UTC)
Re: Race condition with compound keys Marc Nieper-Wißkirchen (15 Aug 2025 18:53 UTC)
Re: Race condition with compound keys Daphne Preston-Kendal (15 Aug 2025 19:09 UTC)
Re: Race condition with compound keys Marc Nieper-Wißkirchen (15 Aug 2025 20:22 UTC)
Re: Race condition with compound keys Marc Nieper-Wißkirchen (15 Aug 2025 19:15 UTC)
Re: Race condition with compound keys Marc Nieper-Wißkirchen (08 Jan 2026 17:59 UTC)

Re: Race condition with compound keys Marc Nieper-Wißkirchen 15 Aug 2025 20:22 UTC

Am Fr., 15. Aug. 2025 um 21:09 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 15 Aug 2025, at 20:53, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> > Am Fr., 15. Aug. 2025 um 20:32 Uhr schrieb Daphne Preston-Kendal
> > <xxxxxx@nonceword.org>:
> >
> > Consider making ordered and hash comparators disjoint types; practice
> > has shown that a comparator that may possess an ordering function or a
> > hash function is not very useful.
>
> It moves in this direction, but maintains compatibility with SRFI 128 in the sense that an implementation can provide both in terms of the same underlying representation(s).
>
> > Also, please consider making a comparator a two- or three-value type
> > instead of a single-value record type. This avoids needless
> > allocation. With a set of syntactic forms, this can be as convenient
> > as the old compound type.
>
> I don’t understand this request. Can you explain it more?

Many use cases will be like

    (make-hash-table (make-hash-comparator x? hash-x x=?))

(where "x?" is not even necessary for a hash table), And the first
thing make-hash-table will do is probably unpack the record. An
R6RS-style interface where the conceptual comparator is modelled as a
pair of values (hash-x and x=?) is more direct.

I would say that an interface using a record is better when there is a
large number of values, but here we only have two.

It also helps decouple data structure APIs (e.g., hash tables) from a
particular representation (given by SRFI 128).

[...]

> Is this actually how *all* garbage collectors handle this situation?
>
> Is it a reasonable restriction to impose on all Scheme garbage collectors for the rest of time?
> (assuming that you intend this SRFI to become part of R7RS large, which I think you do)

When the car or cdr of a pair (or some other compound value) is moved
by a GC, the GC obviously must somehow touch the pair during the same
collection. Whether it moves it as well or puts it in a different
generation or whatever, this is a hook to notify the transport
guardian machinery.

Note that SRFI 254's specification language currently does not
guarantee the behaviour that will likely be seen in practice and that
we have been discussing. It doesn't say that the pair is moved (in the
terminology of SRFI 254) when one of its contents is moved. We would
have to add such a language so that the current-pair-hash guaranteedly
works.

[...]

Marc