iset-search implementations Wolfgang Corcoran-Mathe 08 Dec 2020 20:00 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 08 Dec 2020 20:18 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 09 Dec 2020 18:07 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 10 Dec 2020 12:00 UTC
Re: iset-search implementations Arthur A. Gleckler 10 Dec 2020 16:40 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 10 Dec 2020 16:50 UTC
Re: iset-search implementations Arthur A. Gleckler 10 Dec 2020 16:51 UTC
Re: iset-search implementations John Cowan 11 Dec 2020 02:23 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 11 Dec 2020 02:47 UTC
Re: iset-search implementations John Cowan 11 Dec 2020 03:04 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 11 Dec 2020 18:41 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 12 Dec 2020 10:59 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 14 Dec 2020 17:44 UTC
Re: iset-search implementations John Cowan 16 Dec 2020 15:34 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 16 Dec 2020 15:42 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 31 Dec 2020 18:23 UTC
Re: iset-search implementations John Cowan 07 Jan 2021 21:42 UTC
Re: iset-search implementations Arthur A. Gleckler 08 Jan 2021 04:39 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 08 Jan 2021 13:31 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 08 Jan 2021 23:47 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 09 Jan 2021 13:28 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 10 Jan 2021 23:35 UTC
Re: iset-search implementations Arthur A. Gleckler 11 Jan 2021 00:04 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 11 Jan 2021 06:33 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 11 Jan 2021 00:27 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 12 Jan 2021 14:34 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 12 Jan 2021 18:55 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 18 Jan 2021 09:13 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 19 Jan 2021 18:54 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 20 Jan 2021 10:53 UTC
Re: iset-search implementations Wolfgang Corcoran-Mathe 21 Jan 2021 20:31 UTC
Re: iset-search implementations Marc Nieper-Wißkirchen 11 Dec 2020 08:40 UTC

Re: iset-search implementations Marc Nieper-Wißkirchen 16 Dec 2020 15:42 UTC

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