On 15 Aug 2025, at 20:53, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> wrote:

> Am Fr., 15. Aug. 2025 um 20:32 Uhr schrieb Daphne Preston-Kendal
> <d...@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?

>> If the pair itself is added to the transport cell guardian, will the 
>> guardian notify if its car or cdr only moved, but not the pair itself?
>> Presumably with a typical generational collector, yes – as long as the car 
>> and cdr were not set by modification, because then they may be older than 
>> the pair itself, and therefore they might move without the pair itself 
>> moving?
> 
> Yes, if the pair is younger than the car or cdr, every move of the car
> or cdr after the pair creation will mean that the GC notifies the
> transport cell guardian about the pair.
> 
> If the car or cdr is modified so that it becomes younger than the
> pair, a generational GC will have to move the pair into the younger
> generation (because it has to update it when the car or cdr moves).

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)

> Although this particular scenario works, modifying a key that was
> inserted in any hash table should be considered UB.

Indeed, here I meant that the car and cdr of the pair were set by mutation 
before the pair became (e.g.) a hash-table key.

Though in theory the ‘unstable hash function’ concept could be made to handle 
instability from sources other than heap compaction …


Daphne

Reply via email to