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