Email list hosting service & mailing list manager

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 11 Dec 2020 08:40 UTC

Am Fr., 11. Dez. 2020 um 03:23 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Tue, Dec 8, 2020 at 3:00 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
>>
>> However, whereas `insert' can only insert the element we searched for,
>> the `update' continuation is not so limited; it can insert *any*
>> integer into the set at the point at which the `success' continuation
>> is called.
>
>
> It can indeed insert any element, but "at the point at which ..." is not in the spec, or in SRFI 113 either; the requirement is that the old element is not in the returned set and the new element is.  We have two choices: change the specs or fix the implementations.  As a general rule, in SRFI work we prefer fixing the implementations, and I'm very reluctant to alter existing specs just because some implementations would be somewhat shorter and a hair faster than if they couldn't handle the update continuations in full generality.

The point is not that the implementations cannot be changed so that
they fulfill the current wording of the spec. That wouldn't be very
hard.

The question is more what the "right" behavior of the search procedure
is. If we agree that "search" should have always been limited to
equivalent keys, we should fix the spec (or overwrite the SRFI with a
new SRFI). If, on the other hand, we agree that the current spec is
not so bad at all, we should fix the implementations.

> What is more, I think it's important for ease of use that all set and map search operations have the same interface and semantics, other than the value argument for insert and update.   My pre-SRFI for dictionaries (a dynamic typeclass like comparators) provides generic implementations for 20+ useful operations on all dictionary types, so they have to have consistent behavior.  In particular, dict-search is a primitive, so it needs to work exactly the same way on all dictionaries. There is not yet a proposal for a set or bag typeclass, but there may eventually be.

I fully agree. I didn't remind myself that SRFI 113 has an analogous
procedure, so if we do any changes, we should do them coherently
across all effected APIs.

Marc