Thanks for summarizing the current and the historic state.

I am against (a) and (b) because with them, "search" would stop being
a primitive, in which every other of the standard procedures can be
naturally defined and expressed.

I don't understand your issue with possibility (c). If the set is
eq?-based, the equality predicate should be eq?-based as well,
shouldn't it?

I wouldn't exclude (d) just because it may mean a second traversal. If
we drop (d), we should do it because we think that this would make the
semantics of "search" overly general.

Marc

Am Mi., 16. Dez. 2020 um 16:34 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> Well, I've done a bunch of software archaeology on this feature, and it is now clear that hash-table-search! in the predecessor to SRFI 125 <https://small.r7rs.org/wiki/HashTablesCowan/53/> began life with two user-written continuations, success and failure, as it does today.  The failure continuation was handed a unary add! procedure to insert the key searched for and a value; the success continuation was handed a unary set! (aka update!) that replaced the existing value and a nullary delete! procedure that removed the key.  The continuations were free to call neither of these, which had no effect.  I removed hash-table-search! just before SRFI publication; unfortunately, I have no record of why.
>
> So here are some options that we can implement with post-finalization notes (PFNs), which are only advisory but which historically have been incorporated into R7RS-large.  Each one would imply an alternative implementation that agrees with the PFNs:
>
> a) Remove the new-key argument altogether.
>
> b) Ignore the value of the new-key argument and always use the pre-existing key.
>
> c) Use the new-key argument, but make it an error to provide one that is not the same (in the sense of the equality predicate) as the old key.
>
> d) No PFNs needed; update the implementations to allow arbitrary new-key values.
>
> My general views at present are that (a) is too drastic, (b) is too confusing, (c) is reasonable but won't do what we want in cases like eq?-based sets or mappings (the tree structure has to change), and (d) is reasonable but means we are no longer doing pure traversal.ss
>
> Comments?
>
> On Mon, Dec 14, 2020 at 12:44 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>>
>> On 2020-12-12 11:59 +0100, Marc Nieper-Wißkirchen wrote:
>> > So we have agreed that the -search API should stay as specified and to
>> > change the implementations instead?
>>
>> I've changed the 217 implementation, but I'd still prefer the
>> specification were changed instead.
>>
>> --
>> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>>
>> "I started out as a BASIC programmer.  Some people would say that I'm
>> permanently damaged.  Some people are undoubtedly right." --Larry Wall