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