Email list hosting service & mailing list manager

iset-search implementations Wolfgang Corcoran-Mathe (08 Dec 2020 20:01 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:52 UTC)
Re: iset-search implementations John Cowan (11 Dec 2020 02:24 UTC)
Re: iset-search implementations Wolfgang Corcoran-Mathe (11 Dec 2020 02:47 UTC)
Re: iset-search implementations John Cowan (11 Dec 2020 03:05 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:40 UTC)
Re: iset-search implementations Marc Nieper-Wißkirchen (08 Jan 2021 13:32 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:05 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:28 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