So we have agreed that the -search API should stay as specified and to
change the implementations instead?

Am Fr., 11. Dez. 2020 um 19:41 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-12-10 22:04 -0500, John Cowan wrote:
> > On Thu, Dec 10, 2020 at 9:47 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> > wrote:
> >
> > That's fine.  If `search' is set by convention, then this is, indeed,
> > > an implementation issue.  I may have to fall back to the two-pass
> > > search-then-adjoin approach, since I doubt there's a better way.
> > >
> >
> > If the value searched for is the same (in the sense of eqv?) as the
> > new-value passed to the update continuation, don't do anything: this case
> > arises in "do nothing if the element is already present" cases.  If it is
> > different, do a delete and an insert.  I can't see anything better than
> > that.
>
> Done.
>
> > I haven't looked at the implementation: would it be more efficient to see
> > whether the insert or the delete comes first, and then do the processing in
> > that order?
>
> There might be minor differences in efficiency in some cases, but the
> asymptotic complexity of insert ∘ delete is the same as that of
> delete ∘ insert.  So we'll stick with the former order for now.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "A picture is worth 10k words--but only those to describe the picture.
> Hardly any sets of 10k words can be adequately described with pictures."
> --Alan J. Perlis